in reply to Converting epoch times after 2038

Perl on a 64-bit system can do it. Here's the answer from an x86_64 perl-5.8.8: 

$ perl -we 'warn "".localtime(1<<33), "\n"'
Wed Mar 16 13:56:32 2242

[download]

Update: Time::Local doesn't work after 2038 though.

Replies are listed 'Best First'.
Re^2: Converting epoch times after 2038
by Joost (Canon) on Apr 05, 2007 at 14:48 UTC
[reply]
      Be careful with that on 32-bit platforms, since on 32-bit platforms 1 << 33 will be 2

      ... when perl is not built with 64-bit integer support (here it is "v5.8.8 built for i386-freebsd-64int" (32 bit architecture)) ... 

      
perl -we 'print map { sprintf "%d  %d\n" , $_ , ( 1 << $_ ) } ( 30 .. 
+34 , 60 .. 65 ) '
30  1073741824
31  2147483648
32  4294967296
33  8589934592
34  17179869184
60  1152921504606846976
61  2305843009213693952
62  4611686018427387904
63  -9223372036854775808
64  1
65  2

      [download]

[reply]
[d/l]
Re^2: Converting epoch times after 2038
by Krambambuli (Curate) on Apr 05, 2007 at 10:00 UTC
    Hmmmm...

    I'd be very unhappy to know that the same Perl version would behave differently on a 64-bit system then on a 32-bit system.

    I would consider this a bug - not a feature. Am I missing something in that regard ?

    I imagine using an 64-bit system in development, building an app, letting it out and then get customers complaints about calendar mishappenings - due to the fact that they use 32-bit systems. Scary.
[reply]
      you consider a bug that perl uses libc? hmhmmhm... weird...
      daniel
[reply]

      I too would consider it more a bug than a feature, nonetheless, it seems to be true. I'm getting 7pm Dec 31, 1969 with that one-liner. This is perl, v5.8.8 built for i386-freebsd-64int, running on a 32-bit x86 architecture (Celeron IIRC).

      One supposes this means perl is relying too heavily on the underlying C library for certain things.

      However, the DateTime::Format::Epoch::Unix code that ikegami posted works fine, so maybe the moral of the story is to always use DateTime modules when you're handling dates and times. (I've been doing that for years anyway, because it's better in other ways. A 2038 bug in localtime would just be the icing on the cake.)

      -- 
      We're working on a six-year set of freely redistributable Vacation Bible School materials.
[reply]
[d/l]

        I don't mean to snipe really, but do you think that perl should re-invent every wheel so that it can function identically on across operating systems? Perl doesn't rely "too heavily" on the underlying C library; it relies on the C library just appropriately.

        duff

[reply]

In Section Seekers of Perl Wisdom