Re: A structured format for dates?

[Willy Tarreau <[e-mail]>]

On Tue, Aug 23, 2022 at 06:27:14AM -0700, Tommy Pauly wrote:
> I imagine it's also a lot easier to translate *to* the human readable /
> localized format for a date from the number, since the number is an
> unambiguous form. Parsing dates the other way (from human readable to machine
> readable) is where much of the complexity and ambiguity arises, so a scheme
> that only requires transformations in one direction seems preferable. 

It's the most important aspect here IMHO: almost no error processing is
needed on a scalar. Complex fields require complex processing. Many of
us have been used to stuffing this in their scripts:

   $ date  -d "1970-01-01 00:00:$(EPOCH)"

to convert an EPOCH date to human-readable in the past, and it was quite
an ugly way to abuse a lack of control to do something useful, making
sure that once this bug would be plugged it would break such scripts.
But the equivalent impact in an HTTP field is a problem as we can easily
imagine tools validating a date using a regex and ignoring the time for
example, leaving some room for such stuff to be easy to abuse on simple
implementations.

As such, whenever I have the choice of input format between a simple atol()
and tokenizing elements that I need to feed to localtime() or gmtime(), I
do have a very strong preference for the former.

Regards,
Willy