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:
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk