Re: [Sedate] Robert Wilton's Block on charter-ietf-sedate-01-00: (with BLOCK)

[Edward Welbourne <[e-mail]>]

Justin Grant (14 April 2023 01:56) wrote:
> Hi Rob, I'll try to provide a bit more context around the "Z" issue,
> specifically around the existing practice that we're proposing to
> codify.
>
> The core problem here is that the use case that -00:00 was created for
> is an important use case: how can senders assert when the local date
> and time in the string DOES NOT carry any information about the local
> date and time?

This all boils down to the distinction between
* A date-time expressed in the source's local time, with an offset
  marker to tell you what that local time's offset from UTC was at the
  time, vs
* A date-time expressed in UTC, not because its source is in a place
  subject to UTC as its local time zone, but simply because the source
  chooses to use UTC (which is often a good choice).

In some date-time formats, that include an abbreviation [*] to indicate
the zone in which the date-time is expressed, this can be expressed by
using UTC as the abbreviation.  This would distinguish such a UTC time
from GMT or WET, as local zone names that happen to have zero offset.

[*] Such formats are problematic as, in general, abbreviations are not
    unique; there's a lot of redundancy - of the (seldom more than four)
    letters, the last is usually T for time, another the first letter of
    Standard, Daylight-saving, Summer or Winter, reducing the
    information-content to one bit plus a letter or two, and that's
    before we get into the ambiguities due to zone names being subject
    to l10n, giving different abbreviations in different languages for
    one zone, so that each of the world's many zones potentially uses up
    several abbreviations, in a crowded name-space.  UTC, however, is
    unambiguous.

In formats that use an offset suffix to indicate the use of a local
time, indicating that local time's offset from UTC, Z has long been used
(for "Zero offset", also called "Zulu time" from the radio
voice-protocol name for Z) to distinguish "in UTC" from "in some local
time whose offset from UTC currently happens to be zero".

	Eddy.