Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
At 11:42 -0600 2/22/09, Chris Dolan wrote: Floating point time would be cooler. :-) And it has been in use by Microsoft in the Excel spreadsheet since the Apple Plus which didn't have floating point hardware. But then Excel uses the day as the unit. the second would be better.
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 22, 2009, at 12:39 AM, Brandon S. Allbery KF8NH wrote: On 2009 Feb 20, at 14:36, Chris Dolan wrote: UTC: TAI with an offset, as corrected for the actual revolution of the Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in every day (86399, 86400, or 86401 seconds). Yes, just as I said: a constant offset between each of the proposed Read again; a leap second was added at the end of last year, that's not exactly "constant". You missed the trivial point I was trying to make: the number of seconds between January 1, 1970 UTC (aka time_t epoch) and January 1, 2000 TAI *epochs* is a constant. I did not claim that the time systems differed by a constant. An epoch is an instant in time from which other times are measured, so you can measure UTC time flowing from a TAI epoch and vice versa. Astronomers do this all the time to avoid the complexity that the Earth's rotation precesses, so the time to orbit the Sun once it not exactly the same as a solar year. Astrometric coordinates are thus claimed relative to an epoch, say B1950 or J2000, and can be easily transformed between epochs. Nevertheless, Larry has closed the issue declaring that Perl 6 will use TAI, and I'm cool with that. With just 30-odd lossy exceptions in the last 40 years, we can translate between TAI and time_t as needed. When the OSes catch up and stop using time_t, it will be a glorious day. ... unless we decide to use Stardates instead. Floating point time would be cooler. :-) Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On 2009 Feb 20, at 14:36, Chris Dolan wrote: UTC: TAI with an offset, as corrected for the actual revolution of the Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in every day (86399, 86400, or 86401 seconds). Yes, just as I said: a constant offset between each of the proposed Read again; a leap second was added at the end of last year, that's not exactly "constant". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Fri, Feb 20, 2009 at 2:36 PM, Chris Dolan wrote: > Yes, just as I said: a constant offset between each of the proposed > epochs. No, because the offset is not constant. The delta between TAI and UTC is currently 34 seconds. Two months ago it was 33 seconds. The next time there's a leap second it will change again. And we can't reliably predict when that will be. time_t is indeed easiest to implement, but it doesn't have any way of distinguishing 2008-12-31 23:59:60 UTC from 2009-01-01 00:00:00 UTC. Better to use a basis that has all the information and then transform the value into the lossier form on demand, I think.
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Fri, Feb 20, 2009 at 01:36:12PM -0600, Chris Dolan wrote: : Yes, just as I said: a constant offset between each of the proposed : epochs. But my point remains: from the user's point of view it doesn't : matter which epoch you choose to use behind the scenes, so you might as : well pick the one that's easiest on the software (time_t) and leave the : transformations to the libraries. time_t must die. This is non-negotiable. Larry
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
> Considering time scales, there are three that significantly > interrelate, and no matter what Perl 6 uses internally, it needs to be > able to convert to and from these: > > TAI: continuous count of time using SI seconds as measured by atomic > clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours > in every day. > > UTC: TAI with an offset, as corrected for the actual revolution of the > Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 > minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in > every day (86399, 86400, or 86401 seconds). > > time_t: the value you get by taking the UTC time since Jan 1, 1970 at > midnight and converting to a simple count of seconds, pretending there > have been no leap seconds along the way. > > Right now as I type this it is 17:13:38 UTC. That's 17:14:12 in TAI > (which is 34 seconds ahead of UTC until the next leap second). The > corresponding time_t value is 1,235,150,018, but there have actually > been 1,235,150,042 seconds since the UNIX epoch. Yes, just as I said: a constant offset between each of the proposed epochs. But my point remains: from the user's point of view it doesn't matter which epoch you choose to use behind the scenes, so you might as well pick the one that's easiest on the software (time_t) and leave the transformations to the libraries. Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
Considering time scales, there are three that significantly interrelate, and no matter what Perl 6 uses internally, it needs to be able to convert to and from these: TAI: continuous count of time using SI seconds as measured by atomic clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours in every day. UTC: TAI with an offset, as corrected for the actual revolution of the Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in every day (86399, 86400, or 86401 seconds). time_t: the value you get by taking the UTC time since Jan 1, 1970 at midnight and converting to a simple count of seconds, pretending there have been no leap seconds along the way. Right now as I type this it is 17:13:38 UTC. That's 17:14:12 in TAI (which is 34 seconds ahead of UTC until the next leap second). The corresponding time_t value is 1,235,150,018, but there have actually been 1,235,150,042 seconds since the UNIX epoch.
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Thu, 19 Feb 2009, Chris Dolan wrote: On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Larry Wall wrote: Well, leaving that rant aside, I'm still tempted to say that times in Perl 6 are TAI seconds since 2000. Standard TAI would work too. I've wondered sometimes about the idea of having a dual/moving epoch. By this, I mean that you have eg. two Ints, one which represents the years since 1AD or whatever, and the other of which represents the number of seconds from the beginning of that year. I'm sure many of you can see the advantages and disadvantages of that scheme better than I can, but I thought I'd throw it out there so you can all see whether or not you like it. I don't see the advantage of either of those. TAI 2000 is just UTC 1970 plus a constant offset. 1AD is just UTC 1970 minus a bigger constant offset. Sure, those are slightly easier epochs for a human (ignoring the Julian/Gregorian shift), but not any easier for a computer. UTC 1970 has the big advantage that it is already the underlying value returned by most operating systems and many date/time libraries, so there's no extra additive operation to perform if that's what you want. Having now read the Wikipedia page on time_t, I withdraw my suggestion :). A much more important issue is the use of integer seconds. Milliseconds is a The new interface looks like it will cope with something small fairly well. Dave Rolsky is doing a good job, even though I think there may be room for improvement :). Maybe Perl 6 should be really forward looking and include a time dilation factor so it can be the first language designed from the ground up for interstellar travelers who want to use a non-inertial reference. Or GPS? I'm not a rocket surgeon, but we'd need a $.velocity to calculate that, wouldn't we? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Larry Wall wrote: Well, leaving that rant aside, I'm still tempted to say that times in Perl 6 are TAI seconds since 2000. Standard TAI would work too. I've wondered sometimes about the idea of having a dual/moving epoch. By this, I mean that you have eg. two Ints, one which represents the years since 1AD or whatever, and the other of which represents the number of seconds from the beginning of that year. I'm sure many of you can see the advantages and disadvantages of that scheme better than I can, but I thought I'd throw it out there so you can all see whether or not you like it. I don't see the advantage of either of those. TAI 2000 is just UTC 1970 plus a constant offset. 1AD is just UTC 1970 minus a bigger constant offset. Sure, those are slightly easier epochs for a human (ignoring the Julian/Gregorian shift), but not any easier for a computer. UTC 1970 has the big advantage that it is already the underlying value returned by most operating systems and many date/ time libraries, so there's no extra additive operation to perform if that's what you want. A much more important issue is the use of integer seconds. Milliseconds is a much more useful precision for humans and micro- or nanoseconds is a better precision for machines. I think Time::HiRes with a better API as a builtin would be a big win. Aside: I just learned the other day that Java's Thread.sleep(long millis, int nanos) method just rounds the nanos to the nearest millis and invokes Thread.sleep(long millis). I guess that's a forward looking API for when the OS really can timeslice that small, but it's a little silly today. http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/ classes/java/lang/Thread.java#246 Maybe Perl 6 should be really forward looking and include a time dilation factor so it can be the first language designed from the ground up for interstellar travelers who want to use a non-inertial reference. Or GPS? :-) Chris
