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

From: Wesley Oliver <[email-masked]>
Date: Mon, 6 Mar 2017 15:45:43 +0200

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: [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Mar 2017 14:33:42 +0000

> On 6 Mar 2017, at 13:45, Wesley Oliver <[email-masked]> 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.

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Mar 2017 10:25:47 -0800

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:
> 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
> 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.
> I would like to introduce encoding scheme for UTCOffset, that encodes
> the last timeshift offset
> 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
> MSN messenger: [email-masked] <mailto:[email-masked]>

---

From: Wesley Oliver <[email-masked]>
Date: Tue, 7 Mar 2017 08:21:49 +0200

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 <[email-masked]> wrote:

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

Skype: wezley_oliver

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Mar 2017 23:43:06 -0800

> On Mar 6, 2017, at 10:21 PM, Wesley Oliver <[email-masked]> 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,

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

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

---

From: [email-masked]
Date: Tue, 7 Mar 2017 09:15:09 +0100 (CET)

Hi,

You can already do all of this (except maybe for leap seconds, if you have an app that cares about one second every few years I feel for you), by storing every datetime in UTC (Z timezone of ISO 8601), and converting to local time in the presentation layer, with the TZ database. It's a good idea to convert using the database as a last step anyway, it avoids widespread data corruption when the database has not been updated timely on the local system. And it needs updating since governments can be fickle.

Storing anything in local time like dos-like systems like to do is a recipe for failure (I've even seen some of them invent local time UNIX timestamps !)

See also the W3C datetime profile of ISO 8601 that every one uses practically to transmit datetimes portably. It requires the sender to convert timezones to UTC offset so the rest of the software ecosystem does not have to care about it.

Regards,

-- 
Nicolas Mailhot

---

From: Wesley Oliver <[email-masked]>
Date: Tue, 7 Mar 2017 11:41:20 +0200

HI,

Right guys, you are quite right UTC correct and what use in the backend
systems and for communication.
I managed to get into a rabit hole of solving issues in our system, in
which one our solution store offset with each time, instead of using lookup
tables, to have a history of what setting was.I did manage to clearly
confuse myself, between the formatted one that I was picturing in my mind,
versus the encoded one. some how got confused with UTCOffset being encoded
and us saving a copy of UTCOffset.
So leap seconds, would be the only issues as you correctly stated above.
Sorry for causing so much confusion.

Kind Regards,

Wesley Oliver

On Tue, Mar 7, 2017 at 10:15 AM, <[email-masked]> wrote:

> Hi,
>
> You can already do all of this (except maybe for leap seconds, if you have
> an app that cares about one second every few years I feel for you), by
> storing every datetime in UTC (Z timezone of ISO 8601), and converting to
> local time in the presentation layer, with the TZ database. It's a good
> idea to convert using the database as a last step anyway, it avoids
> widespread data corruption when the database has not been updated timely on
> the local system. And it needs updating since governments can be fickle.
>
> Storing anything in local time like dos-like systems like to do is a
> recipe for failure (I've even seen some of them invent local time UNIX
> timestamps !)
>
> See also the W3C datetime profile of ISO 8601 that every one uses
> practically to transmit datetimes portably. It requires the sender to
> convert timezones to UTC offset so the rest of the software ecosystem does
> not have to care about it.
>
> Regards,
>
> --
> Nicolas Mailhot
>

Skype: wezley_oliver

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 00:38:28 -0800

UTC requires a table to compute deltas if any period spans a leap second. UT avoids that's issue if your optimizing for computing deltas.

Joe

> On Mar 7, 2017, at 12:15 AM, [email-masked] wrote:
> 
> Hi,
>

---

From: [email-masked]
Date: Tue, 7 Mar 2017 16:06:17 +0100 (CET)

De: "Joe Touch" 
> optimizing for computing deltas.

Sure, but not enough software cares about the leap second for UT support to be widespread. UTC is the only realistic option if one wants to use of-the-shelf components.

And there are still many components that botched their UTC migration because of the UTC = local time + offset DOS viewpoint.

-- 
Nicolas

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 08:33:17 -0800

> On Mar 7, 2017, at 7:06 AM, [email-masked] wrote:
> 
> De: "Joe Touch" 

There are trade-offs, certainly. The issue isn't just what format you can implement; it's what format you use as your *primary* encoding, e.g., when storing time stamps in a large database. Pick the wrong one and you spend a lot of cycles converting. No single format avoids conversions for three common uses:

	- to compute deltas or establish strict ordering (UT, now called TA)
	- to interact with official government times (UTC is the standard)
	- to present information to a human user conveniently (people want localtime)

A summary of details:

UT (now called TA, FYI):	native for deltas and ordering; requires leapsecond table to convert to UTC, also requires location and zone/savings table to convert to local time. There are variants of this; the most common  is TA1 (prev. known as UT1).

UTC: most widely supported, requires a leapsecond table to compute deltas, requires location and zone/savings table to convert to local time. UTC is defined as TA1 adjusted for leapseconds.

Local time: typically preferred display for people, requires location and zone/savings table to calculate deltas or convert to UTC. Local time is defined as UTC adjusted for time zone location and daylight savings.

So, optimizing for deltas you would want to use UT as your primary format. Optimizing for interoperation with existing protocols/devices you would use UTC as your primary format. Optimizing for interaction with users you would use local time as your primary format.

And the list above explains what other information you would need if you want to also support formats other than the primary encoding used.

Unix time is (IMO) a poor approximation of UT (or TA), at best.

Joe

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 7 Mar 2017 19:40:48 +0000

> From: Joe Touch [[email-masked]]
> Sent: Tuesday, March 7, 2017 8:33 AM
> [...]
> A summary of details:

this isn't quite right.

> UT (now called TA, FYI):
> native for deltas and ordering; requires leapsecond table to convert to UTC, also requires location and zone/savings table to convert to local time. There are variants of this; the most common  is TA1 (prev. known as UT1).

i think you're thinking of "TAI" ("International Atomic Time"), not "TA" or "TA1".  TAI is a consensus timescale based on numerous atomic clocks around the world (to correct for relativistic/gravitational time dilation).  it theoretically ticks at one SI second per TAI second.  the TAI timescale has exactly 86400 SI seconds per day every day, no matter what.

UT1 is still a thing.  it is based on the rotation of the earth as measured with respect to distant celestial objects.  the UT1 timescale divides each day into 86400 segments called "seconds", which may be shorter or longer than SI seconds depending on how fast the earth is rotating that day.  UT1 is the same everywhere on the earth all the time, but UT1 seconds aren't SI seconds, which is annoying.

because TAI ticks at one SI second and UT1 ticks at 1/86400 earth rotation, TAI and UT1 are divergent.

> UTC: most widely supported, requires a leapsecond table to compute deltas, requires location and zone/savings table to convert to local time. UTC is defined as TA1 adjusted for leapseconds.

"UTC" ("Coordinated Universal Time") is a timescale that (as of about 1972) ticks at the same rate and at the same time as TAI.  UTC is occasionally tweaked with leap seconds (either adding or subtracting a second from the timescale) to keep UTC within 0.9 seconds of UT1.  the last leap second's name in the timescale was "2016-12-31 23:59:60 UTC".  UTC is currently behind TAI by 37 seconds.

> Unix time is (IMO) a poor approximation of UT (or TA), at best.

the Unix timescale is the number of seconds, *not including leap seconds*, since 1970-01-01 00:00:00 UTC, while *also* being synchronized to UTC assuming each day has exactly 86400 seconds.  this is the most broken possible way of dealing with the time.  the positive leap seconds are not representable in this timescale, and all kinds of horrible hacks (like repeating the last second before a positive leap second, or time smearing) are done to compensate.

the Unix timescale *should* be "the number of SI seconds elapsed since 1970-01-01 00:00:00 UTC", and all of the library routines for converting between Unix time and the civil/human timescales (UTC, TAI, local times) should take leap seconds into account as appropriate.

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 11:59:44 -0800

Hi, Michael,

Yes, thanks of for the clarification and catching some errors - notes below.

Joe

On 3/7/2017 11:40 AM, Michael Thornburgh wrote:
> i think you're thinking of "TAI" ("International Atomic Time"), not "TA" or "TA1".

Yes. Darned tiny screen - I thought the "I" was "1". I should have
remembered TAI.

>   TAI is a consensus timescale based on numerous atomic clocks around the world (to correct for relativistic/gravitational time dilation).  it theoretically ticks at one SI second per TAI second.  the TAI timescale has exactly 86400 SI seconds per day every day, no matter what.
>

UT actually has several variants, all of which are intended to sync to
the Earth's rotation. UT0 is star based, and isn't used much. UT1 is
mean solar time (a daily mean), UT1R smooths UT1 to reduce the effect of
tides (like a monthly mean), and UT2 smooths out seasonal variations in
UT1R (like a yearly mean). UTC is TAI with leapseconds, intended to
approximate UT1. They all diverge from TAI because TAI is a physical
constant (at least within the same gravitational frame of reference),
and UT is tied to Earth rotation.

TAI is probably the one you want for relative timekeeping; that's the
one that gets converted to UTC.

> the Unix timescale is the number of seconds, *not including leap seconds*, since 1970-01-01 00:00:00 UTC, while *also* being synchronized to UTC assuming each day has exactly 86400 seconds.  this i…
Agreed - it approximates UT, but without the leapseconds it's just
always wrong.

> the Unix timescale *should* be "the number of SI seconds elapsed since 1970-01-01 00:00:00 UTC", 

I.e., TAI relative to the Unix epoch... except that it starts with an
epoch of 1977-01-01

> and all of the library routines for converting between Unix time and the civil/human timescales (UTC, TAI, local times) should take leap seconds into account as appropriate.

TAI isn't civil or human; it's scientific (physical).

UT (and its variants) are civil/human, as are local times.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 12:11:01 -0800

On 3/7/2017 1:41 AM, Wesley Oliver wrote:
> HI,
>
> Right guys, you are quite right UTC correct and what use in the
> backend systems and for communication.
FWIW, using UTC in the back end makes computing deltas more complex. If
that's a frequent operation, you want to use TAI, not UTC.

Again, base the decision on your most frequent operations. You almost
always need to exchange info in UTC, but if you're computing deltas a
lot, it may be more efficient to convert to TAI when recording the
information.

Joe

> which one our solution store offset with each time, instead of using
> lookup tables, to have a history of what setting was.I did manage to
> clearly confuse myself, between the formatted one that I was picturing
> in my mind, versus the encoded one. some how got confused with
> UTCOffset being encoded and us saving a copy of UTCOffset.  
> On Tue, Mar 7, 2017 at 10:15 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     You can already do all of this (except maybe for leap seconds, if
>     you have an app that cares about one second every few years I feel
>     for you), by storing every datetime in UTC (Z timezone of ISO
>     8601), and converting to local time in the presentation layer,
>     with the TZ database. It's a good idea to convert using the
>     database as a last step anyway, it avoids widespread data
>     corruption when the database has not been updated timely on the
>     local system. And it needs updating since governments can be fickle.
>
>     Storing anything in local time like dos-like systems like to do is
>     a recipe for failure (I've even seen some of them invent local
>     time UNIX timestamps !)
>
>     practically to transmit datetimes portably. It requires the sender
>     to convert timezones to UTC offset so the rest of the software
>     ecosystem does not have to care about it.
>
>     Regards,
>
>     --
>     Nicolas Mailhot
>
>
>
>
> -- 
> --

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 12:20:14 -0800

Hi, all,

FYI - this was all discussed on the IETF main list, starting with a post
on Dec 31, 2016:

https://mailarchive.ietf.org/arch/msg/ietf/To8dZTn9uBJLnzqIvEDPpNnA1rc

We went down all these roads before (including TAI, UTC, and local time).

The real problem, as noted by Michael, is that Unix time is "none of the
above" and has no simple conversion to the above.

And that the IETF doesn't govern the definition of Unix time.

However, I'm pulling together a draft on the this issue in order to
cache this information for future users.

Those interested in collaborating are encouraged to contact me off-list
directly. I'll try to pull in some folks from the Dec/Jan IETF
discussion as well.

Joe

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 7 Mar 2017 22:53:40 +0000

the following table hopefully (if rendered in a monospace font) illustrates the problem with the unix timescale:

elapsed     "unix"      UTC                  TAI
0           0           1970-01-01 00:00:0?  1970-01-01 00:00:10  *
[...]
63072000    63072000    1972-01-01 00:00:00  1972-01-01 00:00:10  **
[...]
1483228824  1483228798  2016-12-31 23:59:58  2017-01-01 00:00:34
1483228825  1483228799  2016-12-31 23:59:59  2017-01-01 00:00:35
1483228826  1483228799  2016-12-31 23:59:60  2017-01-01 00:00:36  ***
1483228827  1483228800  2017-01-01 00:00:00  2017-01-01 00:00:37
1483228828  1483228801  2017-01-01 00:00:01  2017-01-01 00:00:38
1483228829  1483228802  2017-01-01 00:00:02  2017-01-01 00:00:39

*   unix epoch, extrapolated from 63072000.
**  start of the UTC leap second era
*** latest leap second

the main problem with the unix timescale is a conflation between timekeeping and time representation.  the unix timescale is a time representation timescale (like UTC or TAI), but with a major deficiency: not all moments in time have a unique unix time representation.  and the major bug is that people/software use this deficient time representation form for time*keeping* and naive interval measurement -- that is, they treat it as though it was "elapsed time" instead of a presentation form.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Mar 2017 10:13:13 +1100

That sounds like a good plan; discussing it on this mailing list isn't going to involve the right people, and it's not particularly topical here.

Cheers,

> On 8 Mar 2017, at 7:20 am, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 8 Mar 2017 13:15:06 +0900

> cache this information for future users.

I recommend also having a look at "Working with Time Zones", a W3C 
Working Group Note which can be found at 
https://www.w3.org/TR/timezone/. It's less about the physical aspects 
and more about the user-interfacing aspects of time, but also contains 
some advice on data structures,...

Regards,   Martin.

---

From: [email-masked]
Date: Wed, 8 Mar 2017 11:08:38 +0100 (CET)

Hi,

Never never advise anyone to store any datetime in local time, that's a false simplification that always result in long-term problems, with people confusing current local time with past local time with remote local time, pilling up badly thought workarounds, and making mistakes.

Any sane app stores in UTC ot UT with local time conversion done in the UI (with the UI making sure which local time is used is clear to the user).

-- 
Nicolas

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 8 Mar 2017 19:54:54 +0900

> Any sane app stores in UTC ot UT with local time conversion done in the UI (with the UI making sure which local time is used is clear to the user).

In general, this is extremely important and correct. But there's an 
exception. If e.g. a meeting is at 3pm local time in some location, 
independent of daylight saving time, then you better save that fact as 
such, without trying to use UTC and friends.

Regards,   Martin.

---

From: [email-masked]
Date: Wed, 8 Mar 2017 14:17:53 +0100 (CET)

> Any sane app stores in UTC ot UT with local time conversion done in the UI (with the UI making sure which local time is used is clear to the user).

| In general, this is extremely important and correct. But there's an 
| exception. If e.g. a meeting is at 3pm local time in some location, 
| independent of daylight saving time, then you better save that fact as 
| such, without trying to use UTC and friends.

Even then you absolutely do want to save it in UTC (and display it in local time), otherwise you'll have problems as soon as you invite someone who usually lives in another country. Because *his* user agent will interpret local time as *his* local time, the user or the software will then attempt to convert to *your* local time, and botch everything up.

-- 
Nicolas

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Mar 2017 18:00:20 -0700

Hi, all,

On 3/7/2017 12:20 PM, Joe Touch wrote:
> ...
The queue has closed, but I've completed an 00 draft here:

http://www.isi.edu/touch/pubs/draft-touch-time-00.txt

I'd be interested in feedback and further discussion, though I suspect
there is probably a better list for that (any suggestions?)

JOe

---

From: [email-masked]
Date: Sat, 18 Mar 2017 10:20:11 +0100 (CET)

Hi,

While the explanations are nice to have, the document does not really answer the problems of 99,99 % of implementers.

They feel UTC is unfamiliar and hard, they are exposed to a slew of legacy non-standard ways of representing time, they are confused by the number of possible datetime representations, they are confused by variations in local time representations, they are confused by legacy custom time representations in their existing middleware and apps, so they tend to adopt some variation of those legacy conventions, of even cook their own, thinking they will be able to convert them to something else when the time comes to interoperate, and when they'll have made sense of all of this. And then when they have made a thorough mess of their datetime datastore they shout for help, because you know UTC is hard, the proof being they made a mess of things.

The document as it stands buries them under yet more options before offering any advice (and tentative at most).

The basic fact is that right now (state of the art may evolve) the only sane option except for specialized apps is to store all timestamps in UTC, timezone Z, w3c or RFC 3339
 iso 8601 profile, no iso 8601 funky compat options. And convert in the UI in the presentation layer to local time. And keep the local TZ database up to date. And use NTP.

That should be the first paragraph of the document (with a few examples). That would actually help people out of their datetime messes. I know it's not satisfying from a theoretical point of view, it's not innovative, but most implementers are that confused today. The trains here do stop each year for an hour at DST time, the train companies are afraid some automaton somewhere won't cope with the hour change, caring about leap seconds is decades away, and they are one of the few big businesses with yearlong 24/24 activity

Then, for the very small minority that needs better than UTC, the rest of the explanations are welcome. But please not before a very firm and simple SHOULD UTC that will solve most actual problems. Otherwise the document does not help at all, and is counter-productive.

Regards,

-- 
Nicolas Mailhot

----- Mail original -----
De: "Joe Touch" <[email-masked]>
À: "Wesley Oliver" <[email-masked]>, "nicolas mailhot" <[email-masked]>
Cc: "Jim Reid" <[email-masked]>, [email-masked]
Envoyé: Samedi 18 Mars 2017 02:00:20
Objet: Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

Hi, all,

JOe

---

From: "Walter H." <[email-masked]>
Date: Sat, 18 Mar 2017 12:54:49 +0100

On 07.03.2017 17:33, Joe Touch wrote:
>
>
> There are trade-offs, certainly. The issue isn't just what format you 
> can implement; it's what format you use as your *primary* encoding, 
> e.g., when storing time stamps in a large database. Pick the wrong one 
> and you spend a lot of cycles converting. No single format avoids 
> conversions for three common uses:
>
the 3rd point is the biggest problem at all, nearly no software does it 
correct ...

a day begins at 00:00:00 and ends at 23:59:59
(it is really a heavy thing when counting starts at zero ...)
and now look at e.g. the calendar of Microsoft Outlook and look for the 
beginning and ending of a celebration day ...

---

From: Joe Touch <[email-masked]>
Date: Sat, 18 Mar 2017 08:01:06 -0700

Hi, Nicolas,

I agree that the advice is buried and maybe a little less direct than
would be useful.

This issue began twice on the IETF list from suggestions that "we could
do better", especially in avoiding discontinuities or nonuniformity. The
point of this doc is that there's no short-cut.

So here's a summary of what I think should be up front (with a few
paragraphs). Can you let me know if that's what you were expecting?

Joe

------

- system designers SHOULD NOT invent their own time scale because every
gain that might be considered will be offset by significant pain when
coordinating with others later
- there are no shortcuts for dates compared across different systems -
maintaining those dates requires monitoring external info (leap seconds
and time zones), thus:
    - dates SHOULD use UTC in most cases because it is the basis of all
civil time
    - in general, a date system SHOULD maintain related information
about leap-seconds and time zones
            - a date system that requires accurate interval calculation
MUST maintain that information
    - applications that interact with users SHOULD record the location
of a date (e.g., as a time zone)
    - dates MAY use TAI for applications that need to optimize for
interval calculations
    - dates MAY use local time (UTC offset by the local time zone) for
applications that need to optimize for interacting with users

-----

---

From: Joe Touch <[email-masked]>
Date: Sat, 18 Mar 2017 08:18:23 -0700

Hi, Walter,

On 3/18/2017 4:54 AM, Walter H. wrote:
>> e.g., when storing time stamps in a large database. Pick the wrong
>> one and you spend a lot of cycles converting. No single format avoids
> the 3rd point is the biggest problem at all, nearly no software does
> it correct ...
>

Well, here in the US we start at 12:00am and never use zero values.

> and now look at e.g. the calendar of Microsoft Outlook and look for
> the beginning and ending of a celebration day ...

The begin and end of a workday are configurable parameters within
Outlook. All-day events start at the beginning of a day (12am for
12-hour clocks, 00:00 for 24-hour). This is what should be expected.

Can you explain your concern?

Joe

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 18 Mar 2017 13:41:59 -0500

Hi Joe,

> applications that need to optimize for interacting with users

Again I want to emphasize the calendaring and scheduling perspective on 
this: because events may occur in the future, the calendaring system will 
usually store the tuple of (local date-time, time zone id). That way any 
changes to the time zone (e.g. DST rules) that occur prior to the date will 
be properly taken into account. Also, if the event is recurring, the usual 
expectation for users is that the local time remains the same even when the 
DST (or even base time zone offset) changes.

Now, I am not sure whether your document should delve too deeply into the 
calendaring and scheduling use case, but if it does then I strongly suggest 
you cross-post discussion to the calsify mailing list to get feedback from 
the c&s experts there.

On the other hand, it may be sufficient to include a statement along the 
lines of what I outlined above with a reference to a suitable c&s spec. In 
fact, the Calendaring and Scheduling Consortium (CalConnect) has been 
putting together a developer's guide which will include discussion on 
recurrences, time zones, date/time formats etc: 
<http://devguide.calconnect.org>, so maybe a reference to that would also 
be appropriate.

-- 
Cyrus Daboo

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 19 Mar 2017 14:23:25 +1300

> - system designers SHOULD NOT invent their own time scale because every

Heck no. Make that a MUST NOT. Place the invention of more time scales
into the realm of standards design experts who hopefully actually
understand all the implications and whether any exceptional case is
already a solved problem.

> applications that need to optimize for interacting with users

... also IMHO have any mention of other weirdnesses later in the
document be to deprecate them formally and require conversion to one of
the above for any upgraded or new system. Same sort of process as done
with broken crypto components.

Amos

---

From: Michael Douglass <[email-masked]>
Date: Sat, 18 Mar 2017 23:40:11 -0400

It's also worth considering how to avoid this:

https://www.wired.com/2007/04/school_forgets_/

Some time back I had a long conversation with some people from the power 
industry who were very interested in tzdist as they have significant 
problems when people get times wrong. Is the UTC time in the logs the 
real UTC or manufactured by a mis-set machine?

The time we live by is local time and incidents occur in that time 
frame. People assume they can log in UTC and then make the round trip 
back again at some arbitrary point in the future but it doesn't always 
work out so well. At least by storing the local time we are storing the 
time we want to see on that clock on the wall. If we also store the UTC 
offset and teh UTC we can index and sort and we also have a reference to 
show how we got from local to UTC at the time we did it - and we might 
have done it with incorrect timezone information.

> Any sane app stores in UTC ot UT with local time conversion done in the UI (with the UI making sure which local time is used is clear to the user).
Most of the problems we had in the past with timezone changes were a 
result of systems storing time only as UTC.
Again - what matters to the human trying to set up a meeting is the 
local times of each attendee. We convert all those - possibly differing 
- local times to UTC to ensure they agree but my regular meeting is at 
10am before and after DST transitions. When DST rules change what we end 
up changing is not the local time but the UTC.

On 3/18/17 14:41, Cyrus Daboo wrote:
> Again I want to emphasize the calendaring and scheduling perspective 
> on this: because events may occur in the future, the calendaring 
> system will usually store the tuple of (local date-time, time zone 
> id). That way any changes to the time zone (e.g. DST rules) that occur 
> prior to the date will be properly taken into account. Also, if the 
> event is recurring, the usual expectation for users is that the local 
> time remains the same even when the DST (or even base time zone 
> offset) changes.
>
> Now, I am not sure whether your document should delve too deeply into 
> the calendaring and scheduling use case, but if it does then I 
> strongly suggest you cross-post discussion to the calsify mailing list 
> to get feedback from the c&s experts there.
>
> On the other hand, it may be sufficient to include a statement along 
> the lines of what I outlined above with a reference to a suitable c&s 
> spec. In fact, the Calendaring and Scheduling Consortium (CalConnect) 
> has been putting together a developer's guide which will include 
> discussion on recurrences, time zones, date/time formats etc: 
> <http://devguide.calconnect.org>, so maybe a reference to that would 
> also be appropriate.
>

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 12:14:39 +0100

Hello,

> Well, here in the US we start at 12:00am and never use zero values.
then the end is 11:59 pm and never 12:00am (if you want it without seconds)
or 11:59:59pm (if you want it with seconds)
> 12-hour clocks, 00:00 for 24-hour). This is what should be expected.
I  was not talking about a workday ..., I was talking about the general 
problem
the last day of the year ends at 11:59 pm and not 12:00 am - as this is 
the time the next day starts;

by the way 12:00 pm is not defined, as the day has only 24 hours = 1440 
minutes = 86400 seconds
as I said it is a very difficult thing when counting beginns at zero ...
> Can you explain your concern?

talk about sophisticated things, after the basics have been understood ...

Greetings

---

From: Michael Sweet <[email-masked]>
Date: Sun, 19 Mar 2017 08:49:23 -0400

Amos,

> On Mar 18, 2017, at 9:23 PM, Amos Jeffries <[email-masked]> wrote:
>> ...

Um, I don't think any conformance terminology can be applied to people...  And since this is a BCP document, I'm not sure capitalized conformance terminology even makes sense for this document as a whole.

Better to word this non-normatively but otherwise strongly - make a declarative statement, e.g., "time scales are defined by experts so that system designers can choose an appropriate one", and then provide guidance on how to choose the appropriate time scale.

> with broken crypto components.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 06:59:53 -0700

> On Mar 19, 2017, at 4:14 AM, Walter H. <[email-masked]> wrote:
> 
> Hello,
> 
>>> ....

Yes.

> I  was not talking about a workday ..., I was talking about the general problem
> the last day of the year ends at 11:59 pm and not 12:00 am - as this is the time the next day starts;

Why is that a problem? Would it help to think of 12 being 0?

Then we'd have 0:00am (same as 00:00 in a 24-hour system) and 00:00pm (12:00 in a 24-hour system).

Except we couldn't make clock faces using Roman numerals, because they lack a zero. And it wouldn't match the system in current use.

> by the way 12:00 pm is not defined,

Then when did I have lunch yesterday?

Every day starts at 1200am, hits 1200pm at the start of the second half, and ends at 11:59:59.9999999....

Except in leap years when it ends at 11:59:60.9999999...

> as the day has only 24 hours = 1440 minutes = 86400 seconds

That depends on how you define seconds and whether a leap second is involved, but generally, yes.
When you count 0..59 there are 60 items for both minutes and seconds. Counting 12,1,2...9,10,11 yields 12.

You haven't shown a problem yet.

Joe

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 15:55:11 +0100

On 19.03.2017 14:59, Joe Touch wrote:
> Why is that a problem?
because the software behaviour is this invalid ...

>   Would it help to think of 12 being 0?
>
Sorry, the AM/PM system doesn't know of a zero hour ...
> Except in leap years when it ends at 11:59:60.9999999...
wrong, leap years have a February 29th ...
> That depends on how you define seconds
wrong, there is only one definition for second, and that is

in German:  "Die Sekunde ist das 9 192 631 770fache der Periodendauer 
der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des 
Grundzustandes von Atomen des Nuklids Cäsium-133 entsprechenden Strahlung;"
in English: "Thesecondis9192631770 timestheperiodsof 
theradiationcorrespondingto thetransitionbetweenthetwohyperfine levelsof 
theground stateofatomsof thenuclideof Cs-133;"
> and whether a leap second is involved, but generally, yes.
not as image, I showed in words ... "the calendar of Microsoft Outlook 
and look for the beginning and ending of a celebration day ..."

look at this image:
https://cdn.pbrd.co/images/LkqU6dJCk.png
there you see the end of the "appointment" is the beginning of the next 
day which is invalid ...

as I said: "nearly no software does it correct ..."

---

From: Werner Baumann <[email-masked]>
Date: Sun, 19 Mar 2017 16:10:10 +0100

Am Sun, 19 Mar 2017 12:14:39 +0100

> is the time the next day starts;

The moment the next day starts is exactly the same as the moment
this day ends.

Don't mix up moments (points in time) with intervals.

Werner

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 08:45:48 -0700

> On Mar 19, 2017, at 7:55 AM, Walter H. <[email-masked]> wrote:
> 

Application software bugs not related to networking are outside the scope of an RFC.

> wrong, there is only one definition for second,

Please see the draft, which explains how different time scales use different definitions. None of them include both the SI definition below and the definition of a day you provide above, though.

> and that is
> 
> in German:  "Die Sekunde ist das 9 192 631 770fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids Cäsium-133 entsprechenden Strahlung;"
> in English: "Thesecondis9192631770 timestheperiodsof theradiationcorrespondingto thetransitionbetweenthetwohyperfine levelsof theground stateofatomsof thenuclideof Cs-133;"
> not as image, I showed in words ... "the calendar of Microsoft Outlook and look for the beginning and ending of a celebration day ..."
> 
> look at this image:
> there you see the end of the "appointment" is the beginning of the next day which is invalid ...

That is correct if you interpret 'end' as the time when something ceases, not the last instant inside the interval.

But this is far out of scope for the ietf.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 08:51:47 -0700

> On Mar 19, 2017, at 8:10 AM, Werner Baumann <[email-masked]> wrote:
> 

That may be the definition in Outlook, but other systems define intervals other ways.

E.g., in mathematical notation this is the difference between a closed and open interval, such as:

    A: [1,2] closed interval, which includes all values from 1 to 2
    B: [1,2) half open, which includes 1,1.1,...1.999999... but not 2

Your issue seems to be that Outlook isn't clear that it incidents appointments as half closed intervals.

Joe

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 17:09:12 +0100

On 19.03.2017 16:45, Joe Touch wrote:
>   haven't shown a problem yet.
> That is correct ...
no.

> if you interpret 'end' as the time when something ceases, not the last instant inside the interval.
the end of something is the opposite from the beginning ...
when the beginning is included, than the end has also been included ...

we are talking of intervals like
]begin;end[
or
[begin;end]
and never of intervals like
[begin;end[
or
]begin;end]

as I said before: talk of sophisticated after having understood the 
basics ...
> But this is far out of scope for the ietf.
sure?

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 19 Mar 2017 12:23:03 -0500

Hi Joe,

--On March 19, 2017 at 8:45:48 AM -0700 Joe Touch <[email-masked]> wrote:

> That is correct if you interpret 'end' as the time when something ceases,
> not the last instant inside the interval.
>

Actually the IETF does specify that in RFC5545 (iCalendar). iCalendar 
defines the time range <start, end> as start being "inclusive" and "end" 
being exclusive.

It is up to a client to decide how best to present that to a user. When 
displaying timed events to users, it makes sense to show a 1 hour meeting 
at 10 am as "10 am -> 11 am". However, for all-day events, showing a 1 day 
event on Monday as "Monday -> Tuesday" is certainly "odd" as most users 
don't appreciate the difference between "inclusive" and "exclusive". In 
fact some clients will adjust the end date displayed to the user to the 
previous date specified in the iCalendar DTEND property, giving a display 
range that matches most users expectations.

-- 
Cyrus Daboo

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 18:11:00 +0100

On 19.03.2017 18:23, Cyrus Daboo wrote:
> defines the time range <start, end> as start being "inclusive" and 
> "end" being exclusive.
>
> However, for all-day events, showing a 1 day event on Monday as 
> "Monday -> Tuesday" is certainly "odd" as most users don't appreciate 
> the difference between "inclusive" and "exclusive". 
Exact this is the bug, because some logic uses this and follows invalid 
things ...
when the client allows to define, only to show events going on the 
actual day or later, such events are shown, too ...

by the way, the RFC5545 is bullshit, because nobody interprets the following
"working days from monday to friday"
like this ...
the end is always inclusive ...
and should there be calculated correctly, that's all ...

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 10:56:01 -0700

> On Mar 19, 2017, at 9:09 AM, Walter H. <[email-masked]> wrote:
> 

I used precise notation from interval mathematics, where square brackets mean inclusive, and round parentheses mean exclusive.

> as I said before: talk of sophisticated after having understood the basics ...

These issues cannot be coherently understood using colloquial terms.

Monday-Friday typically means [Monday,Friday], but 2pm-3pm typically means [2pm,3pm).

there is no standard across all applications that requires displaying intervals using any particular convention.

And application display is out of scope here.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 10:57:51 -0700

> On Mar 19, 2017, at 10:23 AM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Joe,
> 
> Actually the IETF does specify that in RFC5545 (iCalendar). iCalendar defines the time range <start, end> as start being "inclusive" and "end" being exclusive.

Inside the protocol, it is certainly in scope.

> It is up to a client to decide how best to present that to a user.

Which includes how Outlook presents intervals - both of which are outside the scope of the IETF.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Mar 2017 11:10:43 -0700

On Mar 19, 2017, at 10:11 AM, Walter H. <[email-masked]> wrote:

>> However, for all-day events, showing a 1 day event on Monday as "Monday -> Tuesday" is certainly "odd" as most users don't appreciate the difference between "inclusive" and "exclusive". 
> Exact this is the bug, because some logic uses this and follows invalid things ...

If it is. A bug, it is in the way events are displayed by the client application, which is out of scope.

> when the client allows to define, only to show events going on the actual day or later, such events are shown, too ...
> 

I cannot find that sort of indication (Monday to Friday) in that RFC. 

That RFC isn't as explicit as I would like about whether date ranges are inclusive or exclusive. It doesn't seem to use intervals for many items (e.g., Mon-Fri seems to be indicated by the list "mon, tue, wed, thu, fri", and interval ends must be later than their start (but that doesn't require that the end time be included in the interval; it could just indicate that zero-length intervals must be indicated as instances rather than intervals.

However, the issue you seem to be having is with applications, how they display times, and how they explain that information to their users. Which is out of scope for the IETF.

Joe

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 19:16:43 +0100

> Which includes how Outlook presents intervals - both of which are outside the scope of the IETF.
therefore I'm telling you to store intervals correctly ...

---

From: "Walter H." <[email-masked]>
Date: Sun, 19 Mar 2017 19:22:25 +0100

> I cannot find that sort of indication (Monday to Friday) in that RFC.
Gratulation: you have just given the prove that this RFC is really 
bullshit, because
an event is possible to go from monday to friday ...

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Mar 2017 12:25:01 +1100

[WG chair hat on]

Folks please take this off-list; it's not on topic here.

Thanks,

> On 20 Mar 2017, at 5:22 am, Walter H. <[email-masked]> wrote:
> 
> Gratulation: you have just given the prove that this RFC is really bullshit, because

---

From: [email-masked]
Date: Mon, 20 Mar 2017 10:04:58 +0100 (CET)

Hi,

Sorry, but  the following is not true except for the most basic system

> People assume they can log in UTC and then make the round trip 
> time we want to see on that clock on the wall.

People assume they can log in local time and reconciliate later. But that does not work in actual life. 

When you store in UTC as first step you avoid problem with ambiguous DST hour overlap. The only thing app writers need to remember is that the datetime is in UTC, with simple uniform and clear local-to-UTC on input, and UTC-to-local on display rules. All datetime comparisons and computations happen without offset. Most apps manage this just fine. Errors are easy to identify, the offset from UTC is generally sufficient for them to be glaring. When one source is misconfigured, it's relatively easy to backdate its data to the correct offset because the errors have not propagated past the initial storage UTC conversion (and, really, it's not different from one faulty clock, which operators understand just fine).

When you store in local time apps need to take into account sources that may or may not be on the same offset (remote, local, past, present), that may or may not be the same offset that will be outputed. So every single operation must not forget that every input and every output potentially uses a different offset. You have tricky local-to-local comparisons (with different meanings of local). You get multiple-conversion problems. You get faulty data (hidden by one comparison that masks another, till a correct app is added to the mix). In that context you *will* have mistakes at every step, to such a level I've seen people use the timezone of a neighbouring country that didn't do DST just to purge their systems of problems. A local time system seems easier but I wouldn't trust it my data. I've seen too many expensive failures this way. Local time storage = built-in flackyness.

That's the same reason why conversion from 7bit ASCII-only to local 8bit encodings was such a pit of snakes, to such an extent i18n only really happened when UTF-8 or some sort of unicode was adopted as the interchange and storage standard. Multiple conversions are inherently faulty. Simple to-uniform on input, to-local on disply rules on the other hand work.

People are all too ready to blame their datetime problems on UTC, when one app mishandles them it's the UTC apps problems because "everything would have been fine-and-dandy with good olde local time". When in fact the good olde local time never worked so well, and it's the app that can not manage UTC correctly that needs fixing.

Regards,

-- 
Nicolas Mailhot

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Mar 2017 11:16:14 -0700

One final point; the update will appear in 01, posted when the queue opens.

I will also post where we can continue this conversation, if not on this
list.

see below...

Joe

On 3/19/2017 5:49 AM, Michael Sweet wrote:
>> Heck no. Make that a MUST NOT. ...
IMO, MUST NOT is reserved for behavior that can never work correctly.
That's not the case here, which is why SHOULD NOT is, IMO, more
appropriate.
> Um, I don't think any conformance terminology can be applied to people...  And since this is a BCP document, I'm not sure capitalized conformance terminology even makes sense for this document as a…
BCPs are full of 2119 capitalized wording, and much of it applies to people.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Mar 2017 12:33:13 -0700

Hi, all,

I've submitted the time frame discussion document I mentioned earlier.
Further discussion on this draft will occur on the ART mailing list
([email-masked]).

Joe

-----------

A new version of I-D, draft-touch-time-01.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-time
Revision:	01
Title:		Resolving Multiple Time Scales in the Internet
Document date:	2017-03-27
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-touch-time-01.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-time/
Htmlized:       https://tools.ietf.org/html/draft-touch-time-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-time-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-time-01

Abstract:
   Internet systems use a variety of time scales, which can complicate
   time comparisons and calculations. This document explains these
   various ways of indicating time and explains how they can be used
   together safely. This document is intended as a companion to
   Internet time as discussed in RFC 3339.