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

Let's assume that you want to use time in the following ways:
   
    1) exact time between two events, anywhere on Earth
    2) a time matching those used by most governments

If so, you need to maintain the following information:

    - UT1 (a precise indication of time progressing)

    - the location where the time is being reported

    - a leapseconds table

    - a table indicating timezones and when they are valid

        a variant of which are the daylight savings shifts

Using this information, you can always report:

    UTC, which is UT1 with the given number of leapseconds added, based
on the UT1 date

    local time, which is UTC adjusted for timezone based on location and
UTC date

How you implement this interface is up to you, but NTP provides ways to
get UTC and UT1 already.

Joe




On 3/6/2017 5:45 AM, Wesley Oliver wrote:
> Hi All,
>
> 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 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.
>
> I would like for time to have the property that it is unique in the
> context of planet earth and always increase in its binary value. has
> the observed entropy encoding property.
> For this to happen I need to always encode UTC offset as a property.
> I would like to introduce encoding scheme for UTCOffset, that encodes
> the last timeshift offset
> forward or in reverse, that would allow backward shifting of time of
> events, to be preserved.
> Typically this would required 2600 minutes about 4096bits or 2^12 plus
> sign bit so 2^13,
> which provides a total resolution of 8192 values, where by 2600*2=5200
> +1 are used for UTC minute offset encoding with timeshift forward or
> backwards from last shift.
> The the reaming 8192 - 5201 = could be split and used possibly for
> leap seconds adjustment.
>
> As this would allow writing applications once, that could simply be
> used any where on planet earth.
> Where date and time difference, could easily be computed simply for
> all purposes.
>
>
> Any suggestions on where to start and with whom to speak, or if NTP
> has address this issues
> and we probably should be copying from that.
>
> Kind Regards,
>
> Wesley Oliver
>
>
> -- 
> -- 
> 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>