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

> On Mar 6, 2017, at 10:21 PM, Wesley Oliver <wesley.olis@gmail.com> wrote:
> 
> Hi,
> 
> What I would like to achieve is the following: a time format, that can be used by backend servers
> across the world, that are not susceptible to corner case problems that arise from
> operating time Zone changes or daylight saving changes, which can results in duplicate UTC times stamps,
> since mainly just number of seconds after specific date. 
> 
> https://en.wikipedia.org/wiki/Unix_time

Unix time is not UTC.


> 
> I don't have a problem with the display of time, but only the storage their of, which as of current 
> where countries shift change their times zones or implement daylight savings, or an organization decided
> they going to change their core operating times zone. Under any of these changes, they are causing time dilation and compression. The shift by moving into the future, is not a problem, however, moving time backwards is.
> Moving the UTCOffset backwards in time is a problem, because we going to re-live the delta shift backwards in time.
> 
> This is a problem for me, because I would like to develop a single system that will work across the world once deployed and
> be agnostic to change timezone offset in reverse, in that my system will work regardless.
> 
> If you can think of wanting to sort datetimes across time compression period, you have a problem. The event
> ordering is not preserved. You can create database indexes and things like that, however, you will not be able to
> differentiate the order of events in the delta time shift backwards(compression).

Up to this point in your list, you would want UT, which is UTC without the leapsecond offsets. UT maintains strict ordering and UT deltas indicate the elapsed time between events, regardless of location.

> 
> What I would like to do is have a timestamp, that once written to historical archive, will never need to do
> any lookups of TZ database which is maintained by IANA, when having to do formatting, which is important for speed purposes.

Can you be more precise in indicating your requirements? Whet do you mean by formatting? 

If formatting means recording the time, UT can be recorded any number of ways, depending on the time resolution you seek.

If formatting means printing out the time in a way that is useful to people, you need time zone (which includes daylight savings shifts), location, and leap seconds.

> The only time that the TZ database should be used, is when creating a new date for encoding the little bit of information
> that can deal with UTCOffset  under going a delta change in reverse, by preserving the event order. 

Please check UT, in particular UT1.

> In addition, their are leap seconds and similar events, which will results in time having to be adjusted
> again according to scientists, observations in the near future.

UT does not include leapseconds, so it won't end that correction unless you need to reconvert UT into UTC or local time.

> 
> The other property of the encoding delta UTCOffset is the time difference between two consecutive
> UTCOffset can be computed, with out having to use TZ database. This could potentially be made
> to be 4 or 8, if required, which can be determined from a study which can be the most applicable be
> that would allow for quick, time diff computations, which out having to use TZ database lookups.

UT already does this.

> 
> This solve my current problem of timezone adjustment, daylight saving and changes by organizations,
> to preserver the event ordering, which was my first prize.
> 
> It doesn't solve the issues of being able to do date time difference between any time random events on planet earth.
> 
> Joe Touch, storing of the location where the time is being reported, would be the ultimate way
> in ensure, the event information is preserved. Because if their every is a mess up, then then date times could be corrected
> using what every information similar to TZ database, is most correct at that point in time and the location.

You only need location if you want to convert UT into local time.  

Joe


> 
> Kind Regards,
> 
> Wesley Oliver
> 
> 
> 
> 
> 
>> On Mon, Mar 6, 2017 at 4:33 PM, Jim Reid <jim@rfc1035.com> wrote:
>> 
>> > 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.
> 
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com