Re^4: Timezone Conversion

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

Comment on Re^4: Timezone Conversion

Replies are listed 'Best First'.
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]