Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT This is good for comparison but bad for math. Epoch seconds are NT good for both. That's why *I* use them. You can continue to use NT ISO mumble and have it work for you. I'm not breaking your code. NT There's also the issue that Perl code should (where practical) be NT portable by default. Perl tries to cover up operating system NT oddities. This is one oddity that can (and, I think, should) be NT covered up. I really don't care. As long as I can _easily_ convert it to the system native format. So are you proposing that perl carry/develop/borrow/steal its own date/time library? Because if you do pick an epoch, the native library may not be able to carry you far enough. So pick your poison, are we subject to the whims of the platform or should we stand on our own two feet? Strange thought just crossed my mind. Would having a time object that is understood by perl be sufficient? It would smell and taste like an integer but would otherwise be magical. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On 16 Aug 2000, Chaim Frenkel wrote: "BB" == Buddha Buck [EMAIL PROTECTED] writes: BB I am assuming that the system clocks are set accurately to UTC (or some BB derivative, like (US) Eastern Standard Time). UTC is what time-servers BB report. UTC has leap seconds, which are inserted (or, theoretically, BB deleted) at the end of December 31st and June 30th, as needed. Oh, I was under the impression that they only occur at Dec 31. Nope. BB This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC BB is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or BB 12:00:01 as well. And there is no way to know that ahead of time. Hmm, there are negative leap seconds? I believe there haven't been any yet, and it is not likely that there will be any in the near future, but that there is provision for them. The IERS (International Earth Rotation Service) monitors things and sends out a bulletin twice a year, saying whether there will, or will not, be a leap second on 30 June or 31 December (and which sign it will have if there is one). Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
This discussion should be on the -datetime sublist. Please do not discuss this RFC any further on the main language list. K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Please take this discussion to perl6-language-datetime. Thanks! K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED] whispered: | Um, it's not guaranteed to blow up in 2038. That's an implementation | detail. IF we implement our time values as 64-bit integers (for | instance), we'll long out-live the 2038 deadline. I don't know about anyone else, but I don't intend to care by the time the 2038 deadline comes around. ;-) I hope to still be alive and enjoying my grandchildren by then, but I really hope to not be still programming! -spp
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED] whispered: | Um, it's not guaranteed to blow up in 2038. That's an implementation | detail. IF we implement our time values as 64-bit integers (for | instance), we'll long out-live the 2038 deadline. I don't know about anyone else, but I don't intend to care by the time the 2038 deadline comes around. ;-) I hope to still be alive and enjoying my grandchildren by then, but I really hope to not be still programming! That must sound awfully similar to what the COBOL programmers in the 60's said when they figured that two digits is enough :-) -spp -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: BB I am assuming that the system clocks are set accurately to UTC (or some BB derivative, like (US) Eastern Standard Time). UTC is what time-servers BB report. UTC has leap seconds, which are inserted (or, theoretically, BB deleted) at the end of December 31st and June 30th, as needed. Oh, I was under the impression that they only occur at Dec 31. BB This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC BB is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or BB 12:00:01 as well. And there is no way to know that ahead of time. Hmm, there are negative leap seconds? BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? What do we do with stat(), utime(), sleep(), select(), events, etc. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
At 10:37 AM 8/16/00 -0400, Chaim Frenkel wrote: "BB" == Buddha Buck [EMAIL PROTECTED] writes: BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: Would you be happy with the following edits? BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. time() assumes that the system clock is set to TAI, and does not correct for accumulated leap-seconds. Arithmetic differences between time stamps made using time() may be off by the number of accumulated leap seconds between the two time stamps. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. Exactly. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? Unless you want to have to update perl (or a configuration option) every year, it's probably best to not bother correcting for leap seconds. This is essentially what we do now. The major change here would be a change of epoch (to the TAI epoch) and a documentation of the issues involved. What do we do with stat(), utime(), sleep(), select(), events, etc. stat() returns time stamps (made in the past). utime() sets time stamps. They should be compatible with time(). e.g., "utime time,time,@files" should still set the modify and access times of @files to "now". sleep(), select() both take intervals. The time scale is irrelevant. Will events need time stamps, intervals, or other (please specify)? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: BB stat() returns time stamps (made in the past). utime() sets time BB stamps. They should be compatible with time(). e.g., "utime BB time,time,@files" should still set the modify and access times of BB @files to "now". With or without a translation? BB sleep(), select() both take intervals. The time scale is irrelevant. It does matter, depending upon what an external system may supply. BB Will events need time stamps, intervals, or other (please specify)? Why ever not? I don't think the epoch matters. What matters is that all parties to a programatic communication agree or we can illustrate that it doesn't matter. But if it really doesn't matter, then why have something different than the system epoch. Either one or both of: Perl - Perl cross system will break. Perl - other program same system will break. Pick your poison. I'd rather have cross system break. But if the epoch were available then an adjustment could be made intellegently. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Either one or both of: Perl - Perl cross system will break. Perl - other program same system will break. Pick your poison. I'd rather have cross system break. But if the epoch were available then an adjustment could be made intellegently. I'd take choice (b). I want to be able to write the exact same Perl code and have it deployed on multiple platforms. There's no reason we couldn't introduce a systime() function that returned the true system time. Then time() would always return UNIX epoch time. This seems way more consistent than having time return different values, making you rewrite your code or put ugly OS checks in your code. So, 1. Make all the time/date functions consistent cross-platform 2. Add a systime() for those situations where you really need that specific system's epoch time -Nate
RE: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] wrote: On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED] whispered: | Um, it's not guaranteed to blow up in 2038. That's an implementation | detail. IF we implement our time values as 64-bit integers (for | instance), we'll long out-live the 2038 deadline. I don't know about anyone else, but I don't intend to care by the time the 2038 deadline comes around. ;-) I hope to still be alive and enjoying my grandchildren by then, but I really hope to not be still programming! That must sound awfully similar to what the COBOL programmers in the 60's said when they figured that two digits is enough :-) And the 2038 deadline won't hit us in 2038, it will do it evil work long before that. I have been hit by it some years ago, trying to calculate the 67'th birthday of a person that was 18 years old. Solution: switch to the Date::Calc module for all date calculations and just use time() for short term timings, where the range is just a few days. This way the epoch just doesn't matter! Is would be nice for time() to return a value that has a good precision (1 second is normally not enough), and a reasonable range (eg a dozen centuries each way from now). Henrik Tougaard - FOA, Denmark.
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL Currently, internal time in Perl is maintained via Ctime, which is PRL highly system-dependent. On some systems, this is relative to the UNIX PRL epoch, while others use their own epochs (MacPerl uses 1904, for PRL example). PRL All versions of Perl on all platforms should maintain time both PRL internally and externally as seconds since the UNIX epoch (00:00:00 01 PRL Jan 1970 UTC). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. Unfortunately, the valid range of time supported is easily determined, and disturbingly short: Into the future: to next December 31st or June 30th, whichever is closer. Into the past : to past January 1st or July 1st, whichever is closer. Leap-seconds are a PITA for generic time routines. chaim -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Tue, 15 Aug 2000, Buddha Buck wrote: Leap-seconds are a PITA for generic time routines. Not really. They don't happen very often so you simply have a subroutine that has them all (this is how SLALIB does it). The pain is that you have to release a new version of perl each time a new leap second is added :-) -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Buddha Buck [EMAIL PROTECTED] writes: Leap-seconds are a PITA for generic time routines. Unix time ignores leap seconds. POSIX basically says "don't worry about them" and by and large that works. It means your system clock drifts a little over time and then gets corrected back by xntpd or something, but in practice time on a Unix clock is monotonic. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Thus it was written in the epistle of Nathan Torkington, Chaim Frenkel writes: Why? What is the gain? Perl only runs on the local machine. Epoch seconds are a convenient representation for dates and times. Varying epochs make it an unreliable representation when data are shared. A consistent epoch would fix this. Well then, why 1970? If we're defining our own, why buy into one which is scheduled to blow up in 2038? Why not at the very least start with Jan 1, 2K? Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == God ever arithmetizes. -- Jacobi, Carl == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. BB Unfortunately, the valid range of time supported is easily determined, BB and disturbingly short: BB Into the future: to next December 31st or June 30th, whichever is BB closer. BB Into the past : to past January 1st or July 1st, whichever is BB closer. Sorry, this makes no sense. BB Leap-seconds are a PITA for generic time routines. Why? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Tue, Aug 15, 2000 at 11:17:16PM -0400, Chaim Frenkel wrote: Sorry, I don't buy that. Not every program will be perl. Plus you are assuming that epoch seconds are good everywhere. And even if it were why should any other program use the same epoch. Well, we're not talking about *every* program...just those written in Perl. And epoch seconds *are* good everywhere if we make them good in Perl. The only valid interchange would be to specify the date unambiguously, for example the ISO mumble, help me Jarkko MMDDHHMMSS.fff That's an interface problem where perl meets the rest of the world. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
NOTICE: reply-to set to the -language-datetime list. Ted Ashton writes: Well then, why 1970? If we're defining our own, why buy into one which is scheduled to blow up in 2038? Why not at the very least start with Jan 1, 2K? This works, provided epoch seconds are stored in some form of big integers (either arbitrary precision, or 64-bit). The epoch change would then be fine by me. But epoch changes don't solve the 2038 problem, Unix already tried that before the move to 32-bit integers (they moved the epoch from 1970 to 1971, I think, when their previous size of integer was about to run out of space, then when it ran out again next year they said "yeah, ok, wrong solution" :-). Nat
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
(Reply-to set to -datetime list) Chaim Frenkel writes: NT Epoch seconds are a convenient representation for dates and times. NT Varying epochs make it an unreliable representation when data are NT shared. A consistent epoch would fix this. Sorry, I don't buy that. Not every program will be perl. Bogus argument. This is a non-issue. I'm talking about it being easy to run the same program on different platforms but share data. Optimize for Perl. The only valid interchange would be to specify the date unambiguously, for example the ISO mumble, help me Jarkko MMDDHHMMSS.fff This is good for comparison but bad for math. Epoch seconds are good for both. That's why *I* use them. You can continue to use ISO mumble and have it work for you. I'm not breaking your code. There's also the issue that Perl code should (where practical) be portable by default. Perl tries to cover up operating system oddities. This is one oddity that can (and, I think, should) be covered up. Nat
