jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-sedate-datetime-extended

Commentary: ( as mentioned at IETF 114 ) 
 Thanks
Keys are case-sensitive.  Values are case-sensitive unless otherwise
specified.
Keys are lower-case only.  Values are case-sensitive unless otherwise
specified.
Draft: draft-ietf-sedate-datetime-extended

Commentary: (   )
date-time-hebrew represents the exact same instant, but it informs
calendar-aware implementations that they should project it to the
Hebrew calendar.
date-time-hebrew represents the exact same instant, but it informs
calendar-aware implementations (see calendar) that they should
project it to the Hebrew calendar.
IANA is requested to establish a registry called "Timestamp Suffix
Tag Keys".  Each entry in the registry shall consist of the
information described in registered.  Initial contents of the
registry are specified in registered.
Out of the possible suffix keys, the suffix key "u-ca" is allocated
to indicate the calendar in which the date/time is preferably
presented.
A calendar is a set of rules defining how dates are counted and
consumed by implementations.  The set of suffix values allowed for
this suffix key is as defined by the CLDR data for TR35.  At the time
of writing, this information is collected in CLDR-CALENDAR.
IANA is requested to establish a registry called "Timestamp Suffix
Tag Keys".  Each entry in the registry shall consist of the
information described in registered.  Initial contents of the
registry are specified in tab-registered.
Draft: draft-ietf-sedate-datetime-extended

Commentary: We need a name that people will use until they can say  timestamps ( and maybe even when they can ) . 
 " Extended Timestamps " or " Extended Internet Timestamps " ? 
 RFC 3339 says " Internet Date / Time Format " . That is what sedate says at the moment as well , but that ca n't stay the same . So I 'm considering moving to : Internet Date / Time Format Extended The alternative .... Extended Internet Date / Time Format sounds like a date / time format for the Extended Internet ( EI is actually in use as " Extensible Internet " , which this should n't be confused with ) . I 'd rather call it  , but I have n't found a way to retronym this ... 
 Thanks
Each distinct instant in time can be represented in a descriptive
text format using a timestamp, and ISO8601 standardizes a widely-
adopted timestamp format, which forms the basis of RFC3339.  However,
this format only allows timestamps to contain very little additional
relevant information, which means that, beyond that, any contextual
information related to a given timestamp needs to be either handled
separately or attached to it in a non-standard manner.
Each distinct instant in time can be represented in a descriptive
text format using a timestamp, and ISO8601 standardizes a widely-
adopted timestamp format, which forms the basis of the Internet Date/
Time Format RFC3339.  However, this format only allows timestamps to
contain very little additional relevant information, which means
that, beyond that, any contextual information related to a given
timestamp needs to be either handled separately or attached to it in
a non-standard manner.
We refer to this format as the Internet Extended Date/Time Format
(IXDTF).
all have an internal inconsistency or an unrecognized suffix key/
value, so a recipient MUST treat the Internet Date/Time Format string
as erroneous.
all have an internal inconsistency or an unrecognized suffix key/
value, so a recipient MUST treat the IXDTF string as erroneous.
The extended date/time format is described by the rule "date-time-
ext".
The Internet Extended Date/Time Format (IXDTF) is described by the
rule "date-time-ext".
Here are some examples of Internet extended date/time format.
Here are some examples of Internet Extended Date/Time Format (IXDTF).
Draft: draft-ietf-sedate-datetime-extended

Commentary: Replace " DST " and " daylight savings time " with " daylight saving time " Replace " timezone " with " time zone " Properly capitalize " Unicode Consortium " Improve phrasing 
 If you do n't have time to work further on this very useful PR , I could merge it and fix these three nits . 
 Please do n't add material to this one . We went the opposite direction in the last interim , so I 'm about to remove some of this text . 
 OK , I pushed a commit just before your last comment but will withhold any further changes . 
 Sorry for the unsmooth handling of this PR . I now cherry - picked from this PR . Can I ask you to rebase to main and see what remaining parts you want to pursue ? 
 My last message was too close to the holidays . Do you want to rebase this PR ? Or do you think it is essentially covered by my cherry - picking ? 
 Thanks for the ping , Almost everything was covered by the cherry - picking , but a few things remain . I have rebased the PR to include only those .
'Identifier' contains the key name.
'Identifier' contains the key name.  A key name ending with a hyphen/
minus sign ""-"" is a namespace that covers all timestamp tag keys
beginning with that prefix.
Define a registry that can contain both namespaces and keys.
Namespaces can be recognized by ending with a hyphen/minus.  Actual
keys do not.  See registered for the detailed information (to be
edited).
IANA is requested to establish a registry called "Timestamp Suffix
Tag Keys".  Each entry in the registry shall consist of the
information described in registered.  Initial contents of the
registry are specified in namespaced.
Draft: draft-ietf-sedate-datetime-extended

Commentary: The current draft does not say what it actually means when a timezone name is to a timestamp . Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time ? What if that assertion is not true ? What about future times ? Does the timezone name take precedence over the offset given ( i.e. , the timestamp changes its meaning with political decisions ) or does the offset win ? 
 ( From the SEDATE meeting : " encode the intention " ? ) 
 ( From the SEDATE meeting : " do n't encode the timezone if that is not the overriding information " . ) One use case is documenting the time zone name , though . 
 We now have a clarified scope ( as published in -02 ) . This makes the underlying issue out of scope -- the RFC 3339 semantics prevail . Discuss . 
 essentially is the continuation of this issue with a revised question . The resolution of the question in this PR remains in place . 
 As a description of one path forward , this is good - and it 's sufficient for the proposal that I made . Good threading of the potential needle here .
Future time given as a local time in some specified time zone,
where changes to the definition of that time zone (e.g., a
political decision to enact or rescind daylight savings time)
changes the actual time in UTC time.
Time given as a "floating time", i.e., a local time without
information as to which time zone this local time refers to.
The use of time scales different from UTC, such as TAI.
errors in the applications producing and consuming such a
timestamp.
While the information available is not generally sufficient to
resolve the inconsistency, it may be used to initiate some out of
band processing to obtain sufficient information for such a
resolution.
In order to address some of the requirements implied here, future
related specifications might define syntax and semantics of strings
similar to RFC3339.  Note that the extension syntax defined in the
present document is designed in such a way that it can be useful for
such specifications as well.