"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
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
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:
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
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
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
"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
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" == 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
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
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
|
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
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
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
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
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
"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
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*
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
(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
20 matches
Mail list logo
