Re^3: Timezone Conversion

Time zone conversion. Fun stuff. Looks easy until you get into it.

It's not the math that kills you; it's the human complexity element. There's a reason the Time Zone Database is so large.

If the timezone is given to you as EDT then you're stuck doing your best to avoid or translate ambiguity with what you're given.

I seem to recall the two keys to doing graceful time conversions are knowing what rules are followed in the creation of the timestamp format you are receiving, and knowing what timezone the target should be.

I did a time conversion routine at one point where I insisted I should be able to perform the translation in a single computation (and, frankly, I still argue that I should have been able to), but kept wrapping myself around the axle in handling the odd cases. Probably just wasn't my best head-in-the-algorithm day, but the troubles it kept causing me highlighted what I probably should have done from the start

I finally surrendered and made it a two-step process; convert source time to UTC, then convert UTC to target timezone.

Not only did I get it right without hassle, but the code was astoundingly easier to read and maintain for the poor sucker who had to work on it the next time they changed the DST rules.

I begrudgingly accepted the increased computation cost of two conversions for code that was easier to read and maintain.

Comment on Re^3: Timezone Conversion

Replies are listed 'Best First'.
Re^4: Timezone Conversion by MidLifeXis (Monsignor) on Oct 28, 2015 at 13:43 UTC
I begrudgingly accepted the increased computation cost of two conversions for code that was easier to read and maintain. I have found over time that I normalize input (in this case local TZ => UTC), and regionalize output (UTC => local TZ) -- all data inside of the system is in normalized form. Needing to deal with only one TZ internally to the system is much easier than dealing with unnormalized data anywhere it is encountered. --MidLifeXis	[reply]
Re^5: Timezone Conversion by marinersk (Priest) on Nov 16, 2015 at 22:01 UTC
In retrospect, all systems I've worked on since then either were, or were adjusted to be, following your approach. I can't think of a single exception. Ultimately, if you do any time calc with the data, you wind up saving computation time by keeping everything "native" to UTC. So the perception of increased computational cost simply because I was handling a both-sides-now case were exactly that -- perception.	[reply]
Re^5: Timezone Conversion by oiskuu (Hermit) on Nov 16, 2015 at 23:16 UTC
Concur. It's simply called abstraction (cf ISO OSI layering). Keeping time is one problem, presenting it is another. Abstraction empowers (when done right). For example, manufacturers of common PC timer hardware could have added the functionality for synchronizing to radio signals. "Could". All those op systems that allowed, or even considered, setting RTC to localtime, were disgracefully short-sighted. (Come to think about it, the standard UNIX utilities/pagers ought to have had standard options for recognizing logfile timestamps and rendering them human-readable.)	[reply]
Re^4: Timezone Conversion by stevieb (Canon) on Oct 27, 2015 at 23:18 UTC
The last time DST rules were changed, I had to figure out a way to automate 350 Cisco and Juniper routers (globally) to update so they'd log properly. This change required many devices to have their firmware updated. It was a nightmare for which I wish I still had that code.	[reply]