Re: [Sedate] WGLC on draft-ietf-sedate-datetime-extended-06

["Martin J. Dürst" <[e-mail]>]

Hello Justin, others,

On 2023-01-21 05:50, Justin Grant wrote:
> Hi Martin - I'm planning to go through the latest text later today to do
> other minor editorial cleanup, and I'll try to see if I can clarify some of
> the questions you note in your email.

Many thanks, this is good news.

> Also, there's the example of "2020-01-01T00:00+01:00[+01:00]". Would
>> that be the same as "2020-01-01T00:00+01:00[Etc/GMT+1]" or the same as
>> "2020-01-01T00:00+01:00[Etc/GMT-1]", assuming we needed such a thing,
>> e.g. for North of Swalbard or South of Cape Town?
>>
> 
> [+01:00] is the same as [Etc/GMT-1].  The IANA names for Etc/GMT* zones use
> a reverse sign (apparently for compatibility with POSIX) from the offsets
> used in RFC 3339 timestamps.

This is very good to know. I hope the document becomes as clear as your 
sentence above.

Regards,   Martin.

> Best,
> Justin
> 
> 
> On Thu, Jan 19, 2023 at 5:28 PM Martin J. Dürst <[e-mail]>
> wrote:
> 
>> Hello everybody,
>>
>> I'm not a regular participant, and so I might get something wrong, but
>> I'm rather concerned that with or without the "[sic!]", this will lead
>> to confusion if not actually explained in more detail in the document.
>>
>> In particular, I tried to go through the document and figure out on
>> which occasions which convention is to be used. I wasn't particularly
>> successful. As an example, the document defines the term "IANA Time
>> Zone", but searching through the document, this term isn't used
>> anywhere, although examples such as Europe/Paris turn up in various places.
>>
>> And the example used (Etc/GMT+10) isn't totally helpful, as it could be
>> the same as current Hawaii or Brisbane. (The Pacific ocean is very wide.)
>>
>> Also, there's the example of "2020-01-01T00:00+01:00[+01:00]". Would
>> that be the same as "2020-01-01T00:00+01:00[Etc/GMT+1]" or the same as
>> "2020-01-01T00:00+01:00[Etc/GMT-1]", assuming we needed such a thing,
>> e.g. for North of Swalbard or South of Cape Town?
>>
>> Regards,   Martin.
>>
>> On 2023-01-20 04:50, Justin Grant wrote:
>>> Great news!  Very exciting for this to be moving forward.
>>>
>>> Are we expecting to make any more editorial changes or wordsmithing
>> changes
>>> that won't affect the functional claims of the document?
>>>
>>> I ask because I noticed the following text in the doc draft:
>>>
>>>>    (note that the Etc/GMT+10 time zone has a constant UTC Offset of
>> -10:00
>>>> [sic!])
>>>
>>>
>>> Is the "[sic!]" appropriate here?  Are we intending to keep it in the
>> final
>>> RFC text? And are there other minor proofreading that needs to happen to
>>> finalize the text?
>>>
>>> BTW, re: "[sic!", the IANA names of constant GMT +/- time zones have
>>> reversed signs from the offsets used inside timestamp strings.
>> Explanation
>>> from https://data.iana.org/time-zones/tzdb/etcetera:
>>>
>>> # Be consistent with POSIX TZ settings in the Zone names,
>>> # even though this is the opposite of what many people expect.
>>> # POSIX has positive signs west of Greenwich, but many people expect
>>> # positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
>>> # the abbreviation "-04" and corresponds to 4 hours behind UT
>>> # (i.e. west of Greenwich) even though many people would expect it to
>>> # mean 4 hours ahead of UT (i.e. east of Greenwich).
>>>
>>>
>>> My understanding was that "[sic]" is only used when a quote contains an
>>> error or typo, so that the reader will know that the source of the error
>> or
>>> typo was in the original quote from the original author and not a mistake
>>> made by whoever was transcribing that quote into the document. In this
>>> case, it's weird behavior to maintain POSIX compatibility, but it seems
>> too
>>> strong to say that it's an outright error.
>>>
>>> Cheers,
>>> Justin