Re: gdate integration

[Havoc Pennington <rhpennin midway uchicago edu>]

On Wed, 2 Dec 1998, Aaron Digulla wrote:
> 
> Well, that depends on what you use the date for. When you do a simulation
> of a galaxy, then a date in the range of 40bits (10 billion years is
> already outside of 32 bits, you'll need 34 if you want the sign). So I'd
> base a generic date class on a 48bit year, 24bit for the seconds in the
> year and then I need 50bits for the fractions of the second (upto 10^-15
> which seems the smallest possible amount of time). That means I need a 122
> bit number to store a time. Add one bit for the sign and one for the
> "invalid date" then the rest for the fraction (if someone comes up with an
> even more accurate method to measure time) and you have a 128bit date which
> can store any possible date/time.
> 

I think it's fair to say that GDate will never be able to deal with this
kind of thing. ;-) It's for "everyday dates." I think if we added support
for the year 10 billion, it would just be silly: do you care if the year
10 billion is a leap year? Does it matter what day of the week the
universe will implode? i.e. none of the functions are useful for dates
like that, so people would have to write their own code anyway.  Also no
common operating system supports fraction of a second precision (or even
enough precision to bother fooling with leap seconds).

Perhaps GAstronomicalTime should be written but I think this kind of code
would be useless and wasteful in 99% of the cases you want GDate. Again,
the module is intended for things like calendars, data collected on a
daily basis, etc. - it is meant to be optimal for 95% of cases rather than
merely adequate for 100% of cases. 

Havoc