> "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
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:
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 a
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
> implementatio
> 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 wa
> "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
At 11:17 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>
>NT> Chaim Frenkel writes:
> >> Why? What is the gain? Perl only runs on the local machine.
>
>NT> Epoch seconds are a convenient representation for dates and times.
>NT> Varying epochs
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 fol
> "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
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 integer
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 ab
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
Chaim Frenkel said:
> 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>
(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
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 bi
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* pr
On Tue, Aug 15, 2000 at 10:38:23PM -0400, Ted Ashton wrote:
> 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?
Um, it's not guaranteed to blow up in 2038. That's an implementation
detail.
> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Buddha Buck <[EMAIL PROTECTED]> writes:
>> Leap-seconds are a PITA for generic time routines.
RA> Unix time ignores leap seconds. POSIX basically says "don't worry about
RA> them" and by and large that works. It means your system clock
> "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
>> supp
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> Why? What is the gain? Perl only runs on the local machine.
NT> Epoch seconds are a convenient representation for dates and times.
NT> Varying epochs make it an unreliable representation when data are
NT> sh
On Tue, Aug 15, 2000 at 08:03:44PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Standardize ALL Perl platforms on UNIX epoch
>
>=head1 VERSION
>
> Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
> Date: 14 Aug 2000
> Last-Modified: 15 Aug 2000
> Version: 2
> Mailing List: [EMAIL PROTECTED]
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
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
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
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.
Nat
> 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
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
27 matches
Mail list logo
