RE: [boost] Comments on date/time library

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-01-22 08:00:19

> > But seriously I'm willing to add it, but I don't think I've heard
> > a compelling use case yet...
> 
> I wrote a date formatting function.  This function can take a datetime,
> date, or time duration, and format it to text.  The core however, is
> implemented using datetime_t.  The function implements the format
> as described in Microsoft's documentation:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbaac10/html/acproFormatDate.asp

Any chance you are going to contribute this?
 
> However, to implement format "General Date" (format letter "c"), I
> need to know if the given input contains a date, a time, or a
> datetime.  Since the functions pretty much perform the same
> thing, I have a core that implements functionality for datetime and
> then I use this in the function that implements date/time separately.
> 
> However, to implement the no time I have to query whether the time
> is 0:0:0.000.  This is obviously problematic, since this is a
> perfectly valid time.  For the date, I don't even have a "start date" to
> use.  So I pass the core function a bool that tells it whether to ignore
> the date, and pass in an arbitrary date when I want just the time.
> 
> It would be nicer, though, if I could just pass "not_a_date" or
> "not_a_time".  I could even expect the datetime function to throw
> an exception if the requested format is for "month" and the
> "not_a_date" was passed.

Seems like there will be cases where you will want to print 
the 'not_a_date' value instead of throwing an exception.  
Without a bit more detail, however, it is unclear to me
how this bears on a default constructor.  You can already
test a date to find out if it is not_a_date_time?

> There is also a problem in serialization.  A lot of serialization
> systems first construct an empty struct, and then read in the
> values.  Doing it this way prevents serialization in those
> systems of dates.

Yes, this is a reasonable use case although my preference
for this sort of design is for the factory to use a pre-constructed
prototype object since only rarely does the default constructor
do the right thing -- but it really just depends.

Anyway, I'm seriously considering putting in a default constructor
since their don't really see serious downsides...

Jeff