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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-04-23 16:54:32

----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 23, 2002 3:55 PM
Subject: RE: [boost] Re: reminder about Date/Time formal review

> > 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_Que
stions

Using an unlimited integer type would work, but unless you're going to
include mathematical calculations for the "universal representation" it
seems like a poor choice.  It seems to me that it's easier to simply use a
structure similar to tm, but with more precision.

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

I won't go so far as to call it evil, but multiple methods that provide the
same functionality just add confusion for users.  Which should they use?
Why?  If there's no preference for one over another then why did he have to
stop and figure that out?  And now what should he do, flip a coin every
time?

As for polluting the namespace... the term "polute" is a little strong, but
the fact is that every time you add a name to the system you are adding it
to a namespace.  If the method provides no obvious use, or just duplicates
functionality available through another method, then it is what I'd term
pollution.  And even if the methods exist in different programmatic
namespaces, when they provide the same functionality they still polute the
"conceptual namespace".  I may be picky here, but I really do dislike this
sort of thing.

Bill Kempf