Boost logo

Boost :

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
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.

> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at