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

> On 6 Mar 2017, at 13:45, Wesley Oliver <wesley.olis@gmail.com> wrote:
> 
> Does any one know of an existing standard that deals with TimeZone,Daylight Savings
> encoding, because as of current UTC, doesn't deal with timezone and daylight saving as
> far as I am a where, which means, that for leap seconds and backwards timeshift, their can be duplicate UTC dates.

I’m confused. The whole point of UTC is to have a *universal* time standard that isn’t affected in any way by timezones or daylight savings. It also handles leap seconds.

What is the perceived problem you think needs fixing?

Converting UTC to the prevailing local time (and/or calendar) is a matter of local policy and/or implementation. That is probably impossible to standardise because the local rules are subject to change. For instance Western Samoa(?) recently decided to move from one side of the International Date line to the other. Local clocks there shifted by 24 hours but that had no bearing on UTC at all. Countries change their DST rules or even their timezones too.

Probably the closest thing to a “standard” for mapping between local time and UTC is the TZ database maintained by IANA. This grew out of the zoneinfo stuff that got introduced to Unix-based systems ~25 years ago and is still there today.

> I have take a quick look at the problem and things could be rather small one to solve, but needs some input from others and think make it potential new standard, would be great step forward for all server communicating.

Huh? We have UTC. Unless you’re an astronomer, that’s the only time-keeping standard that's needed. Please explain how it’s defective.

A universal, all-encompassing solution for mapping between local time and UTC is a *HUGE* and never-ending task. Maintaining a database for that information will not be easy either. Good luck.

Received on Monday, 6 March 2017 14:36:08 UTC