Re: [calsify] Fwd: New Timestamp Draft

[Bron Gondwana <[e-mail]>]

On Sun, Jan 24, 2021, at 18:32, Ned Freed wrote:
> However, I don't think you've really made the case that the full date stuff is
> best addressed by packing all kinds of stuff in a single field value. It's not
> like JSON, XML, and so on have no mechanism for specifying a group of related
> values. As such, I question the need to define an additional syntax to do this,
> one that's considerably less flexible.

This idea has been "reinvented" more than once, which suggests that there is demand for it.

> There's also the issue of what constraints are applied to the additional stuff.
> The obvious one is that it MUST NOT be allowed to move the point in time
> of the timestamp around - I don't see this stated anywhere.

For sure you would then need to have both a [+-] and a zone name.  That's an interesting idea, and it does raise the question of what you do if the zone and the fixed offset no longer match by the time you process the date (or indeed, are incorrect immediately).  If the time is a floating value (no Z and no [+-]) then the point in time is also floating.

> > I'm really keen for there to be an RFC which can be referenced by both new
> > calendaring drafts and by other IETF documents, which is developed by this
> > group of people who are already involved in both the ISO work (via Ronald and
> > CalConnect) and the ECMA standardisation effort.
> 
> > Generality has real costs, but so does excess simplicity - if there's not a
> > standard way to describe things that people really need, then they all develop
> > their own extensions.
> 
> Actualy, it's this draft that engages in excess simplicity - the simplicity,
> for example, of assuming that it never makes sense to associate more than
> one set of time zone rules with a timestamp.
> 
> And there's no missing standard here. We have no shortage of standardized
> grouping syntaxes.

The initial justification for this was very much "this is true but said grouping syntaxes don't tend to survived round trips through different systems very well, so we want to capture all the important details in a serialised form".

> > This effort is to capture the extensions that have been needed in the real
> > world already, and standardise them to encourage everyone to extend the same
> > way!
> 
> I'm a very long way from being convinced of this.

I do have one more question (I'm going to do a call for adoption anyway, but I'll take this email thread as a voice against adoption from you unless I hear otherwise)...

Would you be happy if this was either "extends RFC3339" or an entirely separate piece of work that's "only for calendaring systems" - or do you object to the entire principle of doing any work in this space at all?

Thanks,

Bron.
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]