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>