in reply to Re: Converting epoch times after 2038
in thread Converting epoch times after 2038

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.
  • Comment on Re^2: Converting epoch times after 2038

Replies are listed 'Best First'.
Re^3: Converting epoch times after 2038
by ruoso (Curate) on Apr 05, 2007 at 10:42 UTC
    you consider a bug that perl uses libc? hmhmmhm... weird...
    daniel
[reply]
Re: Converting epoch times after 2038
by jonadab (Parson) on Apr 05, 2007 at 10:28 UTC

    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]
        do you think that perl should re-invent every wheel so that it can function identically on across operating systems?

        Only certain necessary wheels. Perl is a high-level language, is supposed to be a *very* high level language. It certainly needs to re-invent data types as necessary to overcome architecture limitations. I don't want to add two integers together and get an overflow. I want it to auto-promote to whatever it needs to. I don't want to add stuff to a string or array and overflow the buffer or smash the stack. I want the necessary RAM to be automatically allocated. And I certainly don't want to add two time values together and get a time in the past because of an overflow. It should automatically promote to (or just be in the first place) however many bits are needed.

        There are things I don't expect perl to re-invent. The filesystem is a good example. Process tables are another. Those things are inherently operating system level concepts, and you don't expect to be able to, for instance, create a hard link on a FAT32 filesystem, or use the same hardcoded file path on different operating systems. But things like arithmetic and dates *should* be the same across all systems.

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

In Section Seekers of Perl Wisdom