Re: [boost] proposal for date implementation

Subject: Re: [boost] proposal for date implementation
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-23 19:32:38

Le 23/04/13 20:48, Shamsher Siddiqui a écrit :
> hi mentors plz review my project and give me suggestion to improve to
> my proposal
>
>
> Name :Shamsher Ahmed
>
Hi Shamsher, thanks for posting your proposal.

I have a general remark.
Your  proposal is more a list of functionalities than a clear design.
H.H. proposal provides a single chrono::date class.
I experimented in TBoost Chrono/Date a different approach than the one 
from H.H. Instead of having a single date class I implemented several 
classes that model the Date concept. Each class has a different 
representation and is the more adapted to some kind of functions.
I made also the difference between two kind of dates, absolute and 
relative dates. H.H. has only one date class that has a 'flag' to signal 
if it is relative or absolute.
Each one of these classes is convertible to the other classes making a 
transformation of the representation.
It is not clear how your library proposal positions respect to Howard 
Hinnant proposal or mine.

What are the functions a class date or a model of a concept Date must 
provide.
What do you think of date iterators?
What about I/O

I don't know if you will have enough time to implement several 
calendars. I think the best would be to provide a good interface for the 
Gregorian calendar, by discussing a lot on this ML.
It would be great if you mark the features as MUST, SHOULD, and COULD in 
order to make clear the priorities.

Would you start from the H.H implementation, mine or would start from a 
white page.

It would be very important to include in the proposal performances 
measures for some of the functions depending on the representation.

More comments below.

Best,
Vicente
> Project Proposal
> Goals & Implemenatations
>
> 1)	   Construction of Date:
> •	Date can be represented in two ways field representation or as an
> serial representation . In field based representation(YMD) date value
> is constructed from individual year,month,and day value in three
> integral value. In serial reprensentation(SERIAL) data values are
> stroed in intergral number of days from an implementation defiend
> epoch date, there is third hybrid version to represent the date
> which implemantd the both representation and it is named
> HH_YMD_SERIAL_X where x represents the size of types in byte.
What representation would you choose for your library?
> •	Providing support for entering the date in form YDM(year,day,month)
> which is lacking  currently in  chrono:date library
Humm, Are you referring to the H. Hinnant Proposal or my implementation 
on TBoost.Chrono/Date?
Why do you think that this constructor is missing?

> •	No invalid dates can be entered considering  range cheaking ,non
> existent date if entered bad_date exception is thrown .
Does it means that the constructor would always check for a valid date?
For performances reasons it has been requested too many times to be able 
to build a date without validating. This doesn't mean that the simple 
way would not use validation.
> •	 Constructing constant object for day,week_day.
>
>     Eg. last/may/2000 represents 31 may 2000
> •	Construction of meta data for date
> 1)	Leap year flag
> 2)	Nth day of month
> 3)	Nth weekday month
Could you elaborate on this?
>
>     2)        Arithematic Operation On date
>
>        Date airthematic can be done on three units i.e
> day,month,year.In chrono date ::calendar(Gregorian    calendar) length
> of month and year is not fixed :
> •	day arithematic
> 1)	Adding number of days to date until  range doesn’t exceed
What do you mean by "until range doesn't exceed"?
>
>
> 3) InterConversion field representation & serial representation
>
>          Some operation are quite fast on field but airthematic
> operation are much faster on serial campared  field representation .So
> it is necessary to provide the inter-coversion so that it can be
> easily converted from one representation to another.
> 1)	Constructing bi-directional conversion of serial  and field by making use
>    of static cache to optimize conversion
Do you mean that you pretend to memoize the conversions?
>
> 4) Building function for week days & date formatting
>
>                               1) weekday of a date used.
>                               2) nextweek day of date used.
>                               3) previous weekday of date used.
>                              4)  finding  number of weeks in month
>                              5) formatting of date according of all types
>
>
> 5)Interoperability with other calendar
>
>       Current chrono::calendar is  Gregorian calendar which exist
> everywhere in date & time library of every programming
> language.(c,c++,java) and ISO 8601 and POSIX. This section provides
> conversion of chrono calendar to client calendar.
> 1)	Conversion of chrono ::calendar to Julian Calendar
> 2)	 Conversion of chrono :: calendar to Hebrew calendar
> 3)	Conversion of chrono :: calendar to hindu calendar
> 4)	Conversion of chrono :: calendar to Chinese calendar
> 5)	Conversion of chrono :: calendar to Buddhist calendar
> 6)	Conversion of chrono :: calendar to Islamic calendar
> Hindu ,Chinese ,Buddhist ,Hebrew(Jewish ) calendars are lunisolar
> calendar with a very little difference.
> Julian, Gregorian are very much similar except the method of finding
> the leap year.
> Islamic calendar is lunar calendar(totally dependent on moon ) which
> is quite unpredicatable. Hence accurate conversion is rare.
>
>