Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

On 3/7/2017 1:41 AM, Wesley Oliver wrote:
> HI,
>
> Right guys, you are quite right UTC correct and what use in the
> backend systems and for communication.
FWIW, using UTC in the back end makes computing deltas more complex. If
that's a frequent operation, you want to use TAI, not UTC.

Again, base the decision on your most frequent operations. You almost
always need to exchange info in UTC, but if you're computing deltas a
lot, it may be more efficient to convert to TAI when recording the
information.

Joe

> I managed to get into a rabit hole of solving issues in our system, in
> which one our solution store offset with each time, instead of using
> lookup tables, to have a history of what setting was.I did manage to
> clearly confuse myself, between the formatted one that I was picturing
> in my mind, versus the encoded one. some how got confused with
> UTCOffset being encoded and us saving a copy of UTCOffset.  
> So leap seconds, would be the only issues as you correctly stated above.
> Sorry for causing so much confusion.
>
> Kind Regards,
>
> Wesley Oliver
>
> On Tue, Mar 7, 2017 at 10:15 AM, <nicolas.mailhot@laposte.net
> <mailto:nicolas.mailhot@laposte.net>> wrote:
>
>     Hi,
>
>     You can already do all of this (except maybe for leap seconds, if
>     you have an app that cares about one second every few years I feel
>     for you), by storing every datetime in UTC (Z timezone of ISO
>     8601), and converting to local time in the presentation layer,
>     with the TZ database. It's a good idea to convert using the
>     database as a last step anyway, it avoids widespread data
>     corruption when the database has not been updated timely on the
>     local system. And it needs updating since governments can be fickle.
>
>     Storing anything in local time like dos-like systems like to do is
>     a recipe for failure (I've even seen some of them invent local
>     time UNIX timestamps !)
>
>     See also the W3C datetime profile of ISO 8601 that every one uses
>     practically to transmit datetimes portably. It requires the sender
>     to convert timezones to UTC offset so the rest of the software
>     ecosystem does not have to care about it.
>
>     Regards,
>
>     --
>     Nicolas Mailhot
>
>
>
>
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
>
>
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com <mailto:wesley.olis@gmail.com>

Received on Tuesday, 7 March 2017 20:12:44 UTC