I am once again asking you to use ISO 8601 for any machine-readable dates that you need to parse from strings. https://www.theverge.com/2024/3/22/24109225/oops-m
@invalidname FWIW ISO-8601 is a very broad, proprietary (!!!) spec. Almost no one implements the whole thing and no one has agreed on a specific subset to use instead (RFC 3339 is too strict for most applications).
The best thing about it is that people think it means something that it doesn’t, and it gets them to mostly use YYYY-MM-DD 😛
@pganssle @invalidname Could you give an example where RFC 3339 is too strict?
@jyrgenn @invalidname RFC-3339 only supports “absolute times”, where you know the exact offset from UTC. This is not sufficient to represent many times in the future, e.g. “2025-03-24 at 13:00 in New York time”, whose relationship to UTC is not fixed, but is semantically the right representation for a meeting scheduled in local time. It is also insufficient to represent more abstract times, or times that take place at a specific time in local time, whatever that is (e.g. “New Year’s Eve”).
@pganssle @invalidname Thinking of it, the only place where I use actual machine-readable *time* and not only a date, is the crontab, and that is as far from ISO 8601 (or RFC 3339, for that matter) as it gets. :–/
@pganssle @invalidname Thanks for the explanation! Most times where I use a time or date in earnest (and in software of my own) are implicitly local time anyway, which doesn’t matter as it is just for local use anyway, not in Internet protocols. (1/2)