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

HI,

Right guys, you are quite right UTC correct and what use in the backend
systems and for communication.
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> 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