Yes, this 32 bit int internal representation of "time" will "run out of gas" in 2038. 64 bit systems appear to be using something else as your code shows (fractions of seconds for example).

To be clear, I would not and do not advocate exporting any sort of internal time representation as binary. The right way to go between systems is as the OP (Original Poster) did: use a string for exported time data. The concept of Unix time is "portable", the exact binary implementation is not.

Yes, if date/time math is needed, I would use a module. Also, converting local time to epoch time is problematic.

As a weird aside: in my city in the US, when we "set our clocks back an hour at 2 AM local" in the fall, this caused some ambiguity and bars could stay open one hour later on that specific day. A law was passed to say that was no longer allowed. But this took a special law targeted at that specific day. I personally think our legislators should have something better to do, but that's just my opinion.

In the years since this thread started, I have learned that it is possible to install Perl modules even when you think that you cannot install a module. However, the code that I presented will still work.

Some sys op advice if you work with international files: Log everything in UTC. The servers in Germany,UK,Japan will log the same UTC time for the same network event. Once you get used to this, and start thinking in UTC, there is no need to convert to local time except for management reports.