Re: support for non-ASCII in strings, was: signatures vs sf-date

--------
Julian Reschke writes:

> > Because sf-date can be a significant performance improvement.
>
> Over an integer? Please elaborate. I see one additional case to
> consider, and another character to skip.

You are right that if we lean heavily into the expectation-driven-parsing
paradigm, the '@' is surplus to requirements.

I would personally have preferred if SF's grammer could be uniquely
parsed without expectation hints, but there were valid gains, in
particular in context of "retrofit" by not making that a strict
requirement.

But that doesn't mean that I think we should add further to the sf
grammars ambiguities if we can avoid it, because that makes debugging
harder.

As a card-carrying time-nut, I also note that '@' makes it much
easier and cheaper to offer a choice of absolute or relative time
in field definitions:

	sf-date => Absolute,

	sf-integer => Relative,

But belongs under Getty's 3rd rule for now.

So if the WG consensus is "loose the '@'", I will loose no sleep over that.

I am far more concerned that we are about to gold-plate second resolution.

I would strongly prefer we based sf-date on sf-decimal instead of sf-integer.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 2 December 2022 12:02:08 UTC