Re: [calsify] New Timestamp Draft

[Eliot Lear <[e-mail]>]

Hi Shane,


> On 25 Jan 2021, at 09:01, Shane Carr <sffc=[e-mail]> wrote:
> 
> A few things:
> 
> - 3339 and 8601-1 are good as a timestamp format.  The extension Ujjwal proposed generalizes those formats based on the demonstrated needs of the ecosystem when dealing with "human dates" as opposed to "computer dates".  It's an interesting observation that timestamps (e.g. log files) are typically used for contemporary events, so the extended 6-digit year format may not really be necessary.  Therefore, I think it would be a reasonable option to keep 3339 unmodified and alive as the timestamp format, and consider the new proposal to be a peer.

Yes, though I really have no problem now obsoleting 2 digit dates, and giving advice for applications to warn of their use (for instance).

> 
> - I see a thread with Eliot Lear, but I don't see where the pros and cons of a combined RFC versus separate RFCs are discussed.  (But this is moot if we were to decide to keep RFC 3339 alive in its current state.)

I only have cons, but see below.

> 
> - The key question solved by this RFC is the data model.  What Ujjwal is proposing is to use a timestamp paired with information about the time zone and calendar system.  Once we agree on the data model (I do), then we can talk about how to package the data.

Yes.  When considering this, let’s be sure that we have live use cases that are important for at least one community to address.  Oddly I don’t think that’s the TZ community, because much of what is being offered is already in iCal.  That being said, there are people more expert here than me, and I am quite happy to be proved wrong.


> Could we use JSON?  Sure, but we still need to specify the structure of the JSON and what form the keys/values can take.  Ujjwal is proposing a string syntax with bracketed annotations because (a) it is already used in the wild, and (b) compared with JSON, strings are more compact [no keys], more compatible [byte array rather than struct/map], and easier to deal with [no need to format/stringify].  I hope not to get into a debate on point (b), but if there are people here who believe that we should stop defining new string syntaxes and instead let JSON (ECMA-404) rule all, then we may need to engage on that topic.

The nice thing about defining the data model is that you can serialize it however you like, and there certainly needn’t be only one way.  This having been said, my only suggestion here is that you start in a way that leverages toolsets that are commonly used for at least the applications that are envisioned.  The nice thing about JSON and XML is that you can’t shake a stick without hitting such a thing (though if you have to lift the XML results, be sure to bend your knees so as not to break your back ;-).  FWIW YANG can help, and I would encourage its use as a description language, even if you have others, simply so that the work can be adopted more broadly by the O&M community.  YANG isn’t very popular with apps people, but what we’re talking about here is so small that maybe one could skate by.

Eliot