Re: [calsify] New Timestamp Draft

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 <ryzokuken@igalia.com> wrote:

> 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:
>
> On 22/01/2021 10.09 pm, Eliot Lear wrote:
>
> > 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?
>
> 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 spec.  They
> presumably thought about it a lot.
>
> 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
>
> --
> Ujjwal "Ryzokuken" Sharma (he/him)
>
> Compilers Hacker, Node.js Core Collaborator and Speaker
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>