Chaim Frenkel wrote:
>
> 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.
This is something that should be easily doable if RFC 73, "All Perl core
functions
> "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
Chris Nandor wrote:
> Interesting. I still think we should have our own real 64-bit time,
> though, since not all platforms will be 64 bit (although by 2020 they may
> be), and perhaps not all of them will be LP64 (and I confess to not know
> what that stands for :).
Simple - LP64 = 'Longs and
At 11:05 +0100 2000.08.23, Alan Burlison wrote:
>Be aware that perl5 already will support a 64-bit time_t if it is
>compiled as a 64 bit application. This is because time_t is defined as
>long, and on LP64 platforms (the majority of 64 bit platforms are I
>think), long becomes 64 bit when apps ar
Russ Allbery wrote:
> > Or, if we're gonna not go along with the standard time_t, might as well
> > make it 64.
>
> 32 bits is clearly insufficient; I would support that.
Be aware that perl5 already will support a 64-bit time_t if it is
compiled as a 64 bit application. This is because time_t
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:
Chris Nandor <[EMAIL PROTECTED]> writes:
> Here are some comments from Matthias Neeracher, the MacPerl author, and
> a few comments from me.
Cool, thanks.
>> Is it? I thought DOS/Windows uses 1900, but I don't know what Perl on
>> these platforms does.
My understanding is that the native epoch
Here are some comments from Matthias Neeracher, the MacPerl author, and a
few comments from me.
>To: Chris Nandor <[EMAIL PROTECTED]>
>Subject: Re: Fwd: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
>Date: Wed, 16 Aug 2000 07:31:25 +0200
>From: Matthias Ulrich Neeracher <[EMAIL PROTECT
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
At 22:07 -0600 2000.08.15, Nathan Torkington wrote:
>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
19 matches
Mail list logo
