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
Mark-Jason Dominus wrote:
> If we're going to standardize on a single time format for all
> platforms, I wish we could choose a good format. Unix time runs out
> in 2038.
Not true. On 64 bit Unix platforms time_t is 64 bit.
Alan Burlison
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
