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

[Marshall]

Wow, I hadn't thought about this code for 7 years!

Yes, there is some wild time weirdness out there and time zone offsets of 30 minutes for sure exist. If I remember right, there used to be a couple of places in the US that used a 30 minute offset for daylight savings time? I hadn't heard of a 15 minute time zone (or daylight time) difference before, but humans are capable of doing some amazingly stupid things! I guess that sort of confusion could be nice as an "excuse" if you are late to an appointment and the other side of the street is using local time 15 minutes ahead of you!

If I were re-doing this, I would add the minutes and seconds into the code, leaving out only the fractions of seconds which cannot be represented by epoch time. 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.

After 7 years, the algorithm remains sound: a) Convert the UTC date/time string into standard epoch seconds. Then, b) ask the local system what local time that epoch time means? I think the code is clear enough that I can leave that straight-forward extension to the reader...The epoch->local time standard function would handle this 30 minute stuff when given enough precision in the epoch time. So a 30 minute offset doesn't fundamentally change anything except the need for more precision.

My advice to always log data in UTC remains. Local time is a presentation thing for management.

[haukex]

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

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

[Marshall]

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.