Re: [calsify] Fwd: New Timestamp Draft

[Ned Freed <[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.

No, what it demonstrates is that there is demand for a way to combine a set of
pieces into a composite. It doesn't demonstate any need to revise the format we
use for specifying a point in time in a readable form, nor does it make the
case that a new syntax is needed.

> > 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.

Well, now we have a problem, because now you have a situation where you have to
understand the meaning of all the pieces in order to be sure you know what time
is being specified. (Saying "this needs further adjustment in some way" is very
different than saying "display the value using this type of calendar".)

This essentially makes the format non-extensible unless you include some sort
of "mandatory/optional" label, never mind what the specification says about
extensibiity.

> > > 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".

Really? JSON and XML don't survive round trips through different systems? 

If you have found this to be the case, you are operating in a different
universe than the one I occupy. Mind you, there's no shortage of problems with
JSON, XML, and ASN.1 for sure (and probably CBOR, although I lack experience in
that area), but I don't tnink surviving transport is one of them. (Well, OK,
the fact that JSON has to be treated as binary is sometimes missed, but this is
a generic JSON issue.)

That said, I think you're talking about semantics, not syntax, here. People
uncover a need to specify the timezone rules or display calendar or whatever
and the base format doesn't support that, and rather than agree on a single
mechanism for grouping this stuff they have instead extended the base
format in different and incompatible ways.

This ia valid argument for standardizing a grouping mechanism. But again, it
falls far, far short of making the case for revising or extending the time
stamp format. That's a different layer.

> > > 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?

Having this be a separate piece of work that uses RFC 3339 as a component
rather than obsoleting or extening it removes my objection to pursuing the
work. Of course the result still needs to interoperate, and this conversation
has convinced me that there's work to do in that regard.

				Ned