Subject: [calsify] ECMAScript Extensions to RFC 3339

From: Shane Carr <[email-masked]>
Date: Tue, 1 Sep 2020 21:55:06 -0500

Dear CalExt experts,

My name is Shane and I am helping push the ECMAScript Temporal proposal,
bringing new date/time types to JavaScript.  It's our version of Joda Time.

I would like your feedback on the following extensions that we are
proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal.

https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md

Of particular interest is our proposed representation of dates in
non-Gregorian calendar systems.

I would appreciate it if you could send feedback!

Thanks,
Shane

---

From: Michael H Deckers <[email-masked]>
Date: Wed, 2 Sep 2020 07:09:26 +0000

> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md

    In the referenced document, you state:

     "The ISO 8601 standard allows durations in units of weeks
      (P3W for three weeks), but weeks are not allowed to appear
      together with any other units."

    This is no longer true for the current version:
    ISO 8601-2:2019 allows notations such as
        P3W2D
        P5Y10W
    along with many others in section 11.3.2, pages 41..42.

    Michael Deckers.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 02 Sep 2020 21:18:07 +1000

My view is that this is worth a revision to 3339; this RFC is widely used, but does not currently offer a representation for date-times with time zone or in non-Gregorian calendars. There is a clear demand for this and standardising a format seems worthwhile for interoperability.

Neil.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 2 Sep 2020 07:30:20 -0400

On 9/1/20 10:55 PM, Shane Carr wrote:
> Dear CalExt experts,
>
> My name is Shane and I am helping push the ECMAScript Temporal 
> proposal, bringing new date/time types to JavaScript.  It's our 
> version of Joda Time.
>

If we're going to parameterize the date/time, why not use something more 
generic, familiar, and extensible, e.g.:

2020-05-22T07:19:35.356-04:00;tzid=America/Indiana/Indianapolis;cs=islamic-umalqura;foo=bar

or

2020-05-22T07:19:35.356-04:00[tzid=America/Indiana/Indianapolis;cs=islamic-umalqura;foo=bar]

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Shane Carr <[email-masked]>
Date: Wed, 2 Sep 2020 15:43:39 -0500

Thank you for the responses!

The "[Europe/Berlin]" suffix is already in common use, e.g. in Java, and
numerous platforms support that syntax.  I feel it would be smart to retain
that form as-is for better interop.

For additional key-value pairs, my latest thought is to have them use the
';' separator Ken suggested.  It would look like this:

2020-05-22T07:19:35.356-04:00[Europe/Berlin];ca=islamic-umalqura;foo=bar

An additional iteration would be to adopt the extensions pattern, similar
to BCP 47, where different prefixes in the key-value syntax are managed by
different standards bodies, and "x" signifies private use.  Since Unicode
manages the calendar system identifiers, this form could look like:

2020-05-22T07:19:35.356-04:00[Europe/Berlin];u-ca=islamic-umalqura;x-foo=bar

Thoughts on the proposed syntax?

What would you recommend as next steps?

Would there be harm if TC39 moved syntax such as that shown above into
Stage 3 (roughly equivalent to Draft Standard in RFC 2026 terminology)?

Thanks,
Shane

P.S. We are having additional discussion on this subject in this GitHub
issue:
https://github.com/tc39/proposal-temporal/issues/293#issuecomment-685960090

---

From: Ronald Tse <[email-masked]>
Date: Sat, 5 Sep 2020 08:12:37 +0000

Hi Shane,

There is a new project in ISO/TC 154 called ISO 8601-3 proposed by CalConnect last year as the third part of ISO 8601.

The syntax is as follows:

Date: {gre}2019-10-11; {jul}2019-10-11

Time: {utc}09:30:20; {gps}09:30:20

Datetime (Timezone): {uset}20191011T09:30:20; {iso.34200.uset}2019-10-11T09:30:20

This syntax is based on the three ISO standards under process, ISO 34100 (reference time scales), ISO 34200 (timezones) and ISO 34300 (calendars).

In this syntax, values can be namespaced, so for example, the ISO 34100 value of {gps} can also be expressed as {iso.34100.gps}, which allows us to handle codes from other authorities e.g. IANA TZs.

Do would want to align syntax used?

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
+=========================================================+

On Sep 3, 2020, at 4:43 AM, Shane Carr <sffc=[email-masked]<mailto:sffc=[email-masked]>> wrote:

The "[Europe/Berlin]" suffix is already in common use, e.g. in Java, and numerous platforms support that syntax.  I feel it would be smart to retain that form as-is for better interop.

For additional key-value pairs, my latest thought is to have them use the ';' separator Ken suggested.  It would look like this:

An additional iteration would be to adopt the extensions pattern, similar to BCP 47, where different prefixes in the key-value syntax are managed by different standards bodies, and "x" signifies private use.  Since Unicode manages the calendar system identifiers, this form could look like:

Would there be harm if TC39 moved syntax such as that shown above into Stage 3 (roughly equivalent to Draft Standard in RFC 2026 terminology)?

Thanks,
Shane

P.S. We are having additional discussion on this subject in this GitHub issue:
https://github.com/tc39/proposal-temporal/issues/293#issuecomment-685960090

On Wed, Sep 2, 2020 at 6:30 AM Ken Murchison <[email-masked]<mailto:[email-masked]>> wrote:

or

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

---

From: Shane Carr <[email-masked]>
Date: Sat, 5 Sep 2020 16:21:31 -0500

Thanks for the info, Ronald!

Could you loop in the editors of these new draft specs (e.g. ISO 34300)
and/or ISO/TC 154?  We've done a great deal of work arriving at our current
state of calendar representation, including a relationship with the Unicode
Consortium, and it would be very good to sync on the syntax and data model
in this area.

Shane

On Sat, Sep 5, 2020 at 3:12 AM Ronald Tse <tse=[email-masked]>
wrote:

> Hi Shane,
>
> There is a new project in ISO/TC 154 called ISO 8601-3 proposed by
> CalConnect last year as the third part of ISO 8601.
>
> This syntax is based on the three ISO standards under process, ISO 34100
> (reference time scales), ISO 34200 (timezones) and ISO 34300 (calendars).
>
> In this syntax, values can be namespaced, so for example, the ISO 34100
> value of {gps} can also be expressed as {iso.34100.gps}, which allows us to
> handle codes from other authorities e.g. IANA TZs.
>
> On Sep 3, 2020, at 4:43 AM, Shane Carr <sffc=[email-masked]>
> wrote:
>
> [email-masked]

---

From: Shane Carr <[email-masked]>
Date: Mon, 14 Sep 2020 13:51:07 -0500

Hi Ronald and others,

To follow up on this: how do you recommend getting in contact with
individuals working on non-Gregorian calendar system specifications?

Over the next couple of months, we would like to have a draft syntax and
data model that satisfies all of the interested parties.  We've been
working on this over in TC39 since late last year, and this is the final
piece of the puzzle.

Shane