Why perl cannot convert unix timestamp over year 2038?

Question

I am trying to use below perl command to convert epoch times to readable localtime:

       bash-3.2$ perl -le print\ scalar\ localtime\ 32503651200
       Thu Mar  9 19:13:52 1911

Below year 2038 is possible to be converted correctly, but for year numbers is greater than 2038 I couldn't get expected result.

Please advise how to fix. Thanks.

Is your perl more than 6 years old (older than 5.12)? – hobbs Sep 23 '16 at 03:50 — hobbs, Sep 23 '16 at 03:50

Schwern · Answer 1 · 2016-09-23T05:03:53.680

8

The year 2038 bug on 32 bit systems was worked around in Perl 5.12.0 (64 bit systems are unaffected by the 2038 bug). I know because I did it (with help). :) Simply upgrade your Perl and the problem (and a lot of others) is solved.

Alternatively, use a date library such as DateTime. It does not rely on system time functions (the root of the 2038 bug), is unaffected by the y2038 bug, and is generally much, much easier to use.

If you can't upgrade Perl and must use localtime and gmtime, you can use Time::y2038 to get versions of those functions unaffected by the 2038 bug.

edited Sep 23 '16 at 05:03

answered Sep 23 '16 at 04:58

Schwern

153,029
25
195
336

Schwern, thanks for this. I will extract the necessity and convert them in Excel. thanks for the explanation. – Fehan Sep 23 '16 at 08:14
3

@Fehan What does Excel have to do with this? – Schwern Sep 23 '16 at 08:17

score 0 · Answer 2 · answered Sep 23 '16 at 04:34

Year 2038 problem

The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 ("the epoch").1 Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the "Y2K problem" (also known as the "Millennium Bug"), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this "Unix time" format

This is explains the problem, but not how to fix it. – Schwern Sep 23 '16 at 04:58 — Schwern, Sep 23 '16 at 04:58

Why perl cannot convert unix timestamp over year 2038?

2 Answers2