Subject: [calsify] New Timestamp Draft

From: Ujjwal Sharma <[email-masked]>
Date: Tue, 12 Jan 2021 04:03:26 +0530

Hi Calsify folks!

I am sorry for the long delay, I got a little sidetracked working on
other things, but I'm happy to inform you all that I have something that
resembles a first draft for the updated timestamps RFC.

Here's where you can find it:

Datatracker:
https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/
GitHub: https://github.com/ryzokuken/draft-ryzokuken-datetime-extended

I would request you all to take a look at it when you can and let me
know what you think. You can file a GitHub issue or email me directly.

There's a few open discussions regarding the exact format and how the
interaction with bodies like the Unicode consortium work, so please feel
free to send me your thoughts regarding that as well.

Also, some references/bibliography is not perfectly functional yet
because I am still relatively new to authoring RFCs using Metanorma but
I'm actively looking into it.

Thanks and looking forward to hear from you,
Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: Steve Allen <[email-masked]>
Date: Mon, 11 Jan 2021 14:42:42 -0800

> GitHub: https://github.com/ryzokuken/draft-ryzokuken-datetime-extended

The term "UTC" was not in use and has no defined meaning prior to 1960.
No radio broadcast time signals were coordinated until April of 1960.
Before 1960 there can only be UT; there cannot be UTC.

This document needs to define the meaning of time using a term other
than UTC for any date prior to 1960.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Steve Allen <[email-masked]>
Date: Mon, 11 Jan 2021 14:56:27 -0800

---

From: Ujjwal Sharma <[email-masked]>
Date: Wed, 13 Jan 2021 23:54:39 +0530

One question: given things move forward smoothly, how do I proceed?
Should I apply for this document to be adopted by the calext WG? I
suppose the fastest way to proceed is to present it at the next IETF
meeting?

Ujjwal

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 14 Jan 2021 12:33:03 +1100

I can do a call for adoption straight away if you like - the next meeting isn't for a couple of months.

Bron.

On Thu, Jan 14, 2021, at 05:24, Ujjwal Sharma wrote:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Ujjwal Sharma <[email-masked]>
Date: Thu, 14 Jan 2021 08:18:20 +0530

Thanks Bron!

I'll make a few more changes, release a 01 version, ask for more
feedback and then let you know, hopefully by the end of this week.

Ujjwal

On 14/01/2021 7.03 am, Bron Gondwana wrote:
>> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>
>> >
>> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>
>> > 
>> [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/calsify>
>>
> 
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 14 Jan 2021 14:04:51 +1100

Sounds great.  Let me know :)

When we do the call for adoption I'll also advertise the fact over to the wider IETF - probably dispatch and tzdata lists at least.

Cheers,

Bron.

---

From: Steve Allen <[email-masked]>
Date: Thu, 14 Jan 2021 08:46:46 -0800

> feedback and then let you know, hopefully by the end of this week.

Also note that cesium hyperfine frequency of 9192631770 had
not been measured until 1958, therefore that cannot be the
definition of a second before that year.  That cesium second
was not adopted by the SI until 1967 August.

Before 1970 the only second which was broadly available was the mean
solar second.  The mean solar second was the basis of available civil
time since the 18th century and the official basis of civil time
from 1884 until 1972.

In order to give meaning to civil timestamps before 1972
the document must mention the mean solar second.

---

From: Ujjwal Sharma <[email-masked]>
Date: Fri, 22 Jan 2021 17:49:19 +0530

Hi Bron, CalExt Friends!

I made a new revision of the draft, which shifts the focus to defining
the syntax/format and defers the standardization of the actual key-value
pairs to sibling organizations like IANA and Unicode Consortium.

I'd love to hear your opinions on this version, which you can find at
https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/,
which can be filed as issues on the GitHub repository or emailed to me
directly. In the meantime, I will address the remaining concerns/polish
issues like fixing the references section.

How "complete" does the document need to be in order to initiate the
call for adoption? If the current version works, can we start it as soon
as possible? Of course, if my understanding of "adoption" is correct,
I'd be happy to iterate on the document further after the adoption by
the WG.

Best,
Ujjwal

On 14/01/2021 8.34 am, Bron Gondwana wrote:
> When we do the call for adoption I'll also advertise the fact over to
> the wider IETF - probably dispatch and tzdata lists at least.
> 
> Cheers,
> 
> Bron.
> 
> 
>> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/
>> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>>
>> >> >
>> >>
>> >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended
>> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>>
>> >> > 
>> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]>>
>> >> <https://www.ietf.org/mailman/listinfo/calsify
>> <https://www.ietf.org/mailman/listinfo/calsify>>
>> >>
>> > 
>> > --
>> >   [email-masked] <mailto:[email-masked]>
>> > 
>> >

---

From: Ujjwal Sharma <[email-masked]>
Date: Fri, 22 Jan 2021 21:46:02 +0530

Hi Steve!

Sorry for taking a while before responding to your emails.

> than UTC for any date prior to 1960.

and

> Also note that cesium hyperfine frequency ... cesium second

> was not adopted by the SI until 1967 August.

For both of these, I like have to point out that none of these
definitions were added in this update and belong to the original RFC
(RFC 3339). That said, if folks agree that the original RFC incorrectly
defines these terms and they need to be updated, I'd be happy to correct
them in the next revision of the draft.

That said, I would have to point out that my knowledge in this space is
rather limited and therefore it would be best if you recommended exactly
what the replacement should be. To take things further, you could also
make a pull request to the project at
https://github.com/ryzokuken/draft-ryzokuken-datetime-extended
or email me a git patch if you prefer that.

Thanks,
Ujjwal

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2021 17:39:10 +0100

Hi,

RFC 3339 or ISO 8601 is used all over the place.  It’s used in logging, email, and a great many other things.  Before the IETF goes monkeying with it, could the authors discuss what is driving this change?  What do you want people to do that they didn’t do before, and what do you want them to stop doing, and why?

Also, I suggest that this work should go through DISPATCH.  There are a lot of other questions.  Here’s one: is the IETF really the right organization to do this work in? ISO wrote the underlying spec.  They presumably thought about it a lot.

Eliot

> On 22 Jan 2021, at 17:16, Ujjwal Sharma <[email-masked]> wrote:
> 
> Hi Steve!
>

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Jan 2021 10:47:18 -0800 (PST)

> RFC 3339 or ISO 8601 is used all over the place.  It’s used in logging,
> email, and a great many other things.  Before the IETF goes monkeying with it,
> could the authors discuss what is driving this change?  What do you want people
> to do that they didn’t do before, and what do you want them to stop doing,
> and why?

+1. The stability of this specification has been invaluable.

> Also, I suggest that this work should go through DISPATCH.  There are a lot
> of other questions.  Here’s one: is the IETF really the right organization to
> do this work in? ISO wrote the underlying spec.  They presumably thought about
> it a lot.

+1. And if there's some sort of liason with ISO or whoever is responsible 
for this, they should be engaged.

				Ned

---

From: Ujjwal Sharma <[email-masked]>
Date: Sat, 23 Jan 2021 02:38:36 +0530

Hey Elliot!

I answered a couple of these questions in a previous CalExt meeting, but
here goes another attempt at getting them out in writing:

> RFC 3339 or ISO 8601 is used all over the place.  It’s used in logging, email, and a great many other things.  Before the IETF goes monkeying with it, could the authors discuss what is driving this…

There are many cases in which the information stored within a timestamp
is not enough and implementations need to include additional information
for various reasons. It is common knowledge that Java and Linux among
other implementations include an IANA timezone id suffixed to the
regular timestamp, but I think of it as an unfortunate situation that
this format is not standardized. The aim of this proposal is to:

1. Standardize the existing format.

2. Expand the format to include more information (in case of us, ECMA
TC39, this includes the calendar information which is the biggest reason
that drives us to expand the currently existing format).

3. Make the expansions generalizable enough to allow any additional
future information to be included.

4. Make certain parts of the RFC further future-proof, for example
remove the 2/3-year deprecated format and allow the expanded 6-year
format, which makes this RFC up to date with the newer versions of ISO8601.

> Also, I suggest that this work should go through DISPATCH.  There are a lot of other questions.  Here’s one: is the IETF really the right organization to do this work in? ISO wrote the underlying s…

We are already collaborating with the folks over at CalConnect, to
ensure that formats like ISO8601 end up adopting these additions as
well, but the IETF RFC would need to be updated as well, and it helps
ECMA TC39 refer to the RFC when using this format.

I hope these answers help clarify our positions. Feel free to ask me for
any further clarifications.

Thanks,
Ujjwal

---

From: Shane Carr <[email-masked]>
Date: Fri, 22 Jan 2021 16:59:44 -0600

Hi all,

I also wanted to point out that this proposed revision to RFC 3339 makes
the syntax a bit more flexible without sacrificing backwards
compatibility.  Implementations that do not concern themselves with IANA
time zones or Unicode extensions can simply ignore those annotations, which
occur at the end of the string.  Since the IANA time zone suffix is already
in common use, and this proposal leverages that existing syntax, we expect
that the impact on the ecosystem will be small.

Shane

On Fri, Jan 22, 2021 at 3:09 PM Ujjwal Sharma <[email-masked]> wrote:

> email, and a great many other things.  Before the IETF goes monkeying with
> it, could the authors discuss what is driving this change?  What do you
> want people to do that they didn’t do before, and what do you want them to
> stop doing, and why?
>
> > Also, I suggest that this work should go through DISPATCH.  There are a
> lot of other questions.  Here’s one: is the IETF really the right
> organization to do this work in? ISO wrote the underlying spec.  They
> presumably thought about it a lot.
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 24 Jan 2021 14:15:35 +1100

The document is plenty complete enough for a call for adoption!  I shall do so now.

You are exactly correct that it's possible to do further iteration after adoption.

Thanks,

Bron.

---

From: Steve Allen <[email-masked]>
Date: Sat, 23 Jan 2021 23:05:05 -0800

> them in the next revision of the draft.

Yes, I see.

> or email me a git patch if you prefer that.

A lot of history has to be condensed for this, but I have attempted to
add enough clarification to make it clear that timestamps before 1972
are defined entirely differently than after 1972.
I believe that I have made a fork and requested a pull.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Jan 2021 11:32:48 +0100

Bron,

I’m sorry, but I have both substantive and procedural problems with you moving forward like this.  Let me start with the procedural.  This work isn’t in calext’s charter.  You are specifically chartered to tackle several extensions to the iCalendar format, and that is it.  This is not an extension to that format.  This is a change to a standard that is used extremely broadly.

And this leads me to the substantive concern: this change is backward incompatible with  3339.  The ABNF in 3339 is clear: the stamp ends "time-offset" ("Z" / time-numoffset).  Adding “suffix" blow up in any yacc/bison-based parser and who knows what else.  Just imagine all the perl, awk, php, and python that whacks this stuff.

In a great many cases, there is no means to negotiate the extension.  Let me give you two examples:

Logging software commonly uses 3339 both for generation and for parsing, and the parsers themselves are notoriously fragile to the point that I do not believe any of them would entertain any changes to 3339.  The ecosystem is so vast that there is no hope of enumerating it.  To test this, imagine what damage changing any other field to syslog would cause.
Calendaring software, though in a smaller ecosystem, will have older versions that may well fail to parse.

I am not saying that 3339 can never be updated, but before it is, it should be clear that (a) it is broadly needed, not just by calendaring, and (b) that there is reason to believe that the change will be broadly adopted, again not just by calendaring.  If it’s just the calendaring ecosystem, you have properties and parameters to use.

Eliot

> On 24 Jan 2021, at 04:15, Bron Gondwana <[email-masked]> wrote:
> 
>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>,
>> >> > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>
>> >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>>
>> >> >>
>> >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>
>> >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>>>
>> >> >> >
>> >> >>
>> >> GitHub: https://github.com/ryzokuken/draft-ryzokuken-datetime-extended <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>
>> >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>>
>> >> >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>
>> >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>>>
>> >> >> >
>> >> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>> >> <mailto:[email-masked] <mailto:[email-masked]>>>
>> >> >> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> >> <https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>>
>> >> >> <https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> >> <https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>>>
>> >> >>
>> >> >
>> >> > --
>> >> >   [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> >> >
>> >> >
>> >> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> >> > https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> >> <https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>>
>> >> >
>> >>
>> >> --
>> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> >> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> >> <https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>>
>> >>
>> >
>> > --
>> > https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> >
>> 
>> --
>> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> 
> 
> --
> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>

---

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 24 Jan 2021 21:53:05 +1100

I'll ask you the same question I asked Ned, which is "do you object to this work being taken up by the IETF at all, or just to it obsoleting 3339?"

I will also point out that for all that we've talked about making the IETF more welcoming to newcomers, this has been a really unfriendly experience for Ujjwal.  Maybe that's my fault, but I'm sorry Ujjwal for misleading you if so.  I did raise that this work was coming in the "any other business" at IETF110's DISPATCH, but without a draft there was very little guidance.  Indeed the minutes of last dispatch say:

Bron Gondwana: RFC3339 extension
* Javascript notation format is looking for a standard serialisation.

Harald Alvestrand:
* We should have done this in the 90s!  It was a mistake not to do it then.

Neil Jenkins:
* we do need a serialisation format

Where to discuss: calsify or tzdata lists, but probably calsify is best.

You can watch a video of the exact discussion here: https://youtu.be/d871MoUgAKU?t=6418

...

Regardless, it appears that the right next venue for this document is DISPATCH at IETF110.

Regards,

Bron.

On Sun, Jan 24, 2021, at 21:32, Eliot Lear wrote:
> And this leads me to the substantive concern: this change *is *backward incompatible with  3339.  The ABNF in 3339 is clear: the stamp ends "time-offset" ("Z" / time-numoffset).  Adding “suffix" blow up in any yacc/bison-based parser and who knows what else.  Just imagine all the perl, awk, php, and python that whacks this stuff.
> 
>  * Logging software commonly uses 3339 both for generation and for parsing, and the parsers themselves are notoriously fragile to the point that I do not believe any of them would entertain any changes to 3339.  The ecosystem is so vast that there is no hope of enumerating it.  To test this, imagine what damage changing any *other* field to syslog would cause.
>  * Calendaring software, though in a smaller ecosystem, will have older versions that may well fail to parse.
> 
> *Attachments:*
>  * signature.asc

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Jan 2021 13:47:17 +0100

Hi Bron,

Thanks for taking my views into account.  Please see below.

> On 24 Jan 2021, at 11:53, Bron Gondwana <[email-masked]> wrote:
> 

I think it depends on what you mean by “this”.  If “this” means modifying the 3339 timestamp format directly, then yes, I would object - at this point (maybe not later, but see below).  If “this” means finding a means to provide additional information to a consumer relating to the context of timestamp, then no I would not object to the IETF taking it on.  In other words, I am not convinced that the current draft is the correct starting point, which is why I recommended that this be aired in DISPATCH.

I hinted above at a potential way forward for Ujjwal: if we take a step back and separate the information model from its representation I think things would go a little better.  For instance, the draft defines two new information elements: time zone and a calendar tag. Discussing those two extensions (or any others) and their value constraints may be helpful.  Then discussing how to represent them in different environments may be helpful as well.  In this way, you make use of at least one existing architectural building block while creating one of your own.

You have a lot of tools in your toolbox.  You could easily create a JSON array that represents that model that includes a 3339 timestamp and whatever additional information you believe appropriate.  You could use YANG or your favorite way to do that.  If you use YANG, you get an XML serialization for free as well.  And once you’ve done that for JSON you’ve also pretty much picked up CBOR, which is nice.  Pick your own favorite representation.  The nice thing about YANG is that all the O&M people will give you love for that.

If people want to add that object to logs, I imagine that some day SYSLOG will get around to being “JSONified” and/or “CBORified” (there were already attempts at XML… sigh).  And if people using the existing SYSLOG format want to include that information today using the existing format, they can just pick up the information elements and represent them in the log components that they control.

You could do all of this without updating 3339.  Still, there may be a need to update 3339, but it has to be done quite carefully, with all ramifications, side effects, and alternatives being considered.  Also, I could easily imagine both an update to 3339 to do things like obsoleting two-digit years and a new draft to handle extensions a’la the above.

> 
> I will also point out that for all that we've talked about making the IETF more welcoming to newcomers, this has been a really unfriendly experience for Ujjwal.  Maybe that's my fault, but I'm sorry Ujjwal for misleading you if so.

I apologize too if my comments are late, but this is pretty foundational.

> I did raise that this work was coming in the "any other business" at IETF110's DISPATCH, but without a draft there was very little guidance.  Indeed the minutes of last dispatch say:
> 
> You can watch a video of the exact discussion here: https://youtu.be/d871MoUgAKU?t=6418 <https://youtu.be/d871MoUgAKU?t=6418>
> 
> ...
> 

Yes, please.  Not that I object to this being discussed here prior to adoption, so long as the chairs don’t mind (that’s entirely your call and entirely not mine).

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Jan 2021 16:07:16 -0500

First, everyone, meet Francesca Palombini (added on CC), who will be
your new AD starting in March.

I do have to agree with Eliot that obsoleting 3339 is well out of
charter for calext.  What you quote below from what you said in
dispatch, "Javascript notation format is looking for a standard
serialisation", is not the same thing as "revising and obsoleting RFC
3339".  As Eliot points out, there are ways to include extra
information in jCalendar, for example, without changing the basic
date/time strings that are used in many places.  Changes to the 3339
date/time strings will have ramifications all over the Internet, and I
think that needs its own working group and a lot of publicity to make
sure we're getting "everyone" who cares about it, rather than doing it
where people think we're only dealing with calendaring protocols.

I *am* sorry if this has been frustrating, unfriendly, or otherwise
unpleasant for Ujjwal, and I'm quite sensitive to that.  I'm happy to
help in any way I can, as I know Bron and Eliot (and Francesca) are.
But we can't just handle this document in an inappropriately light
way... the effect will be too far-reaching, even if exactly the
changes that Ujjwal's draft suggests should turn out to be perfect.

Do we think we should be chartering a working group to revise and
obsolete RFC 3339?  If so, let's get a draft charter for that and get
the process started.  Do we need a standard JSON wrapper around what
3339 specifies, either as a stop-gap or as a permanent solution?  Then
maybe calext is the place to do that, and let's shift to working on
that.

Barry, ART AD

On Sun, Jan 24, 2021 at 5:53 AM Bron Gondwana <[email-masked]> wrote:
> Attachments:
> signature.asc

---

From: Shane Carr <[email-masked]>
Date: Mon, 25 Jan 2021 23:29:39 -0600

Thanks everyone for the thoughtful responses.

At this point, I have seen three general types of concerns over
Ujjwal's proposal:

1) Concerns that we need to spend more time exploring the space before
jumping into a solution
2) Concerns over compatibility with systems that want a standalone timezone
syntax without Ujjwal's annotations
3) Proposition that we should standardize a JSON/YANG schema before a
string syntax

My responses:

1) Ujjwal's proposal is the result of quite a bit of work within ECMA-TC39
and liaising with some folks in the Unicode Consortium.  I worry that
chartering a new working group would duplicate much of the work that has
already gone into this proposal (not to mention setting ECMA back further).

2) Two very clear paths forward have been presented: publish the proposal
as a new RFC, and then either keep 3339 the way it is, or publish a
successor to 3339 with 6-digit years but no annotations.

3) I discussed earlier why I feel a string syntax is warranted.  I'm happy
to continue this discussion if we can narrow it down to this point of
contention.

Shane

On Mon, Jan 25, 2021 at 3:07 PM Barry Leiba <[email-masked]> wrote:

> > I'll ask you the same question I asked Ned, which is "do you object to
> this work being taken up by the IETF at all, or just to it obsoleting 3339?"
> >
> > I will also point out that for all that we've talked about making the
> IETF more welcoming to newcomers, this has been a really unfriendly
> experience for Ujjwal.  Maybe that's my fault, but I'm sorry Ujjwal for
> misleading you if so.  I did raise that this work was coming in the "any
> other business" at IETF110's DISPATCH, but without a draft there was very
> little guidance.  Indeed the minutes of last dispatch say:
> >
> > I’m sorry, but I have both substantive and procedural problems with you
> moving forward like this.  Let me start with the procedural.  This work
> isn’t in calext’s charter.  You are specifically chartered to tackle
> several extensions to the iCalendar format, and that is it.  This is not an
> extension to that format.  This is a change to a standard that is used
> extremely broadly.
> >
> > And this leads me to the substantive concern: this change is backward
> incompatible with  3339.  The ABNF in 3339 is clear: the stamp ends
> "time-offset" ("Z" / time-numoffset).  Adding “suffix" blow up in any
> yacc/bison-based parser and who knows what else.  Just imagine all the
> perl, awk, php, and python that whacks this stuff.
> >
> > Logging software commonly uses 3339 both for generation and for parsing,
> and the parsers themselves are notoriously fragile to the point that I do
> not believe any of them would entertain any changes to 3339.  The ecosystem
> is so vast that there is no hope of enumerating it.  To test this, imagine
> what damage changing any other field to syslog would cause.
> > I am not saying that 3339 can never be updated, but before it is, it
> should be clear that (a) it is broadly needed, not just by calendaring, and
> (b) that there is reason to believe that the change will be broadly
> adopted, again not just by calendaring.  If it’s just the calendaring
> ecosystem, you have properties and parameters to use.
> >
> > Eliot
> >
> >
> > >> GitHub:

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jan 2021 08:04:28 +0100

Just to add...

> help in any way I can, as I know Bron and Eliot (and Francesca) are.

^^^
Absolutely, for my part.

Eliot

---

From: Shane Carr <[email-masked]>
Date: Tue, 26 Jan 2021 01:06:28 -0600

Correction: item 2 should say "standalone timestamp syntax", not
"standalone timezone syntax".

On Mon, Jan 25, 2021 at 11:29 PM Shane Carr <[email-masked]> wrote:

> 2) Concerns over compatibility with systems that want a standalone
> timezone syntax without Ujjwal's annotations
>> > Logging software commonly uses 3339 both for generation and for
>> parsing, and the parsers themselves are notoriously fragile to the point
>> that I do not believe any of them would entertain any changes to 3339.  The
>> ecosystem is so vast that there is no hope of enumerating it.  To test
>> this, imagine what damage changing any other field to syslog would cause.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 Jan 2021 10:53:24 +0000

Hi,

> your new AD starting in March.
Wellcome Francesca!
> changes that Ujjwal's draft suggests should turn out to be perfect.
I am sorry I was not paying enough attention to this topic earlier, but 
if you are looking for more feedback, this is my 2p:
> the process started.
No. I would rather leave RFC 3339 as is, for reasons that Ned and Eliot 
have stated.
> Do we need a standard JSON wrapper around what
> 3339 specifies, either as a stop-gap or as a permanent solution?

Yes, I can see this work as being useful. But I don't think we need to 
replace RFC 3339, an extension (or wrapper) which just defines extra 
stuff is going to be much quicker to complete and will have less resistence.

I think draft-ryzokuken-datetime-extended is a good starting point for 
this effort, once a lot of original RFC 3339 text is deleted from it.

Best Regards,

Alexey

> Then