RE: [boost] Re: reminder about Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-23 15:55:34

> I don't follow what you mean by it being "foolhardy to attempt to recreate
> from scratch".  Eventually I'd hope that GDTL provides all the functionality
> provided by their algorithms, and in at least one sense of the term this
> would be a "recreation from scratch".

I meant that I don't want to create all new algorithms, test data, and
approaches.  Yes, the code has been rewritten from into C++, but
we don't have to start from zero in trying to get test data.  A really
hefty part of the development of this library is in test cases, so I
appreciate getting help there. So if someone wanted to add a calendar 
documented in R&D I would suggest they start there rather than
begin from scratch.  That said, if someone comes along with a great 
implementation of some calendar we should still considering it. 
And again, I think for C to C conversion we should adopt the R&D
approach precisely because it is well documented.

> Agreed, but the "universal representation" I'm proposing makes this less
> likely to be a real issue for most time systems.  Instead of using a single
> integer type to represent the time elapsed since the epoch, we'd use
> multiple integral types for seconds, minutes, hours, days, etc.  If you need
> smaller resolution we simply need to add milliseconds or nanoseconds.  If
> you need larger resolution you add months, years, etc. (OK, I realize that
> these aren't universal and it may be more precise to pick some other unit of
> time that is precise here).  The addition of these will cause a need to
> recompile everything, but it won't effect the interface or implementation of
> any conversion routines.  Are there still issues?  Yes, but none that I'd
> consider show stoppers.

I'm not as confident as you, but I agree that there will be a practical
solution for most of the 'mainstream' time systems.  And I think 
that the distance has to be defined in terms of something like
picoseconds.  According to a calculation that I haven't really checked we 
will need about 108 bits for a range of trillions of years at that
resolution.  Thus we were conjecturing that a 128 bit representation
would be a sufficient representation.  Given this I would like to
have an unlimited integer type to help with this.  Anyway, the discussion
is captured here:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Open_Questions
 
> > One final point on this topic.  I see no reason why an individual
> > time or date system should be 'restricted' from providing a direct
> > conversion to another form.  And I'm generally inclined to add a
> > few common ones directly.  For example, I could see extending the
> > gregorian::date to have a method mjd() that would return the modified
> > julian day. 
>
> Not with out either polluting the namespace with duplicate methods for the
> same functionality, or breaking existing code.  That's the root of the
> reason why I think the universal representation approach is so important.

I don't see having 2 ways as fundamentally evil.  Also, there might
be conversion efficiencies that can be can from direct conversion.
As for the namespace, adding a function to a class doesn't pollute
the namespace.

Jeff