Re: Converting epoch times after 2038

[jonadab]

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.)

[duff]

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.

[jonadab]

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.