At 02:00 PM 8/14/00 -0500, Jonathan Scott Duff wrote:
>On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote:
> > At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote:
> > >On Mon, Aug 14, 2000 at 06:13:13PM -0000, Perl6 RFC Librarian wrote:
> > > > =head1 TITLE
> > > >
> > > > Maintain internal time in Modified Julian (not epoch)
> > >
> > >How would this be stored? As a floating point number? What about
> > >sub-second accuracy? To get seconds you'd need about 5.15 decimal
> > >places (let's just call that 6) I think it should be stored as 2 numbers,
> > >the julian day and the seconds into that day.
> >
> > How 'bout 100ns ticks from base date, stored in a 64-bit number? That
> > should see us into Y30K, assuming the integer is signed...
>
>Sure, but does that mean that perl will support 64-bit ints on all
>platforms?
A working bigint package's on my list of wants for perl 6.
>I think automagic type promotion to/from bigints would be
>great but it would swamp anyone doing lots of date/time calculations.
I'm not sure anyone does that much in the way of time/date work that it'd
make a difference. Besides, we're talking internal here--time() may still
return Unix epoch seconds for compatibility reasons.
FWIW, standard floats handle these dates without loss through sometime in
Y2.3K, IIRC. (Wrote code to take quadword time in this format and turn it
into something perl could use once)
>I'm just guessing that manipulating time values is much more common than
>arithmetic with large numbers.
>
>Or will we have special purpose stages in between able-to-use-native
>and need-to-use-something-bigger, one of which could be 64-bit?
We may have ints of various sizes. (Or we may make it look that way but
really fake it... :) Hard to say yet.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
