Re^4: convert UTC time to system time zone's time with perl default method

Epoch is basically a 32 bit int representing number of seconds since an arbitrary date that is related to the release of Unix. So the fractions of a second cannot be represented.

Or 64 bits on newer systems, see the Year 2038 problem. Also, the way I look at it is that the concept of "Unix time" (non-leap seconds since Jan 1st, 1970 00:00:00 UTC) is portable, which is separate from the storage of that value. For example, it's possible to get Unix time with fractional seconds (this is on Linux):

$ perl -MTime::HiRes=gettimeofday -e 'printf "%d.%06d\n", gettimeofday
+'
1488014647.609340
[download]

Personally I'd always advocate using an appropriate module to do date/time math instead of homegrown solutions, usually DateTime.

Comment on Re^4: convert UTC time to system time zone's time with perl default method Download Code

Replies are listed 'Best First'.
Re^5: convert UTC time to system time zone's time with perl default method by Marshall (Canon) on Feb 26, 2017 at 20:26 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^5: convert UTC time to system time zone's time with perl default method
by Marshall (Canon) on Feb 26, 2017 at 20:26 UTC

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.

[reply]