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

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

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).

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.
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.
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.

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.

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.

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