The original ISO has some very niche stuff in it people have no interest in supporting. Whereas 3339 is pretty much just the bread and butter of the format.
In the context of the train departure time, it's easy to work out what is meant by a weekday 00:37 arrival, but if they were divorced from each other for some reason, weekdays at 24:37 would be easier to interpret.
Being awake past midnight brings up a few challenges with calendars. My watch wil count a late (late) night walk against tomorrow, not against today. As a human, I consider "tomorrow" as "after I've gone to sleep", not "after midnight". 00:37 is still very much tonight.
For example, this Pacific Surfliner timetable [PDF] from Amtrack, where one train goes 11:36P -> 12:10A for one leg
https://www.amtrak.com/content/dam/projects/dotcom/english/p...
Here's a bus timetable [PDF] from Canada that goes 23:45 -> 00:00 -> 00:07: https://www.gotransit.com/static_files/gotransit/assets/pdf/...
Looking at my copy of the draft of the 4th edition of ISO 8601, it seems they removed the 24:00 feature so now times have to be between 00:00 and 23:59. A shame, I think.
https://developers.google.com/transit/gtfs/reference#stop_ti...
It creatively abuses the lack of range checking in the format, and stretches the human facility of "knowing what I mean". It does not match a real time, though, because no clock shows this time as a current time.
While neat, it's a hack, a way to bend the notion of time, and as such, it ought to cause problems. Fortunately, airlines never seem to use this hack, and are able to indicate "00:37 next day".
As for a shift that starts friday 24:00, you could argue that the shift is actually a 'Saturday 00:00 shift', but the users didn't see it that way; they are scheduling Friday nights shifts and want an extra person late Friday evening.
Also you're describing seems to be intervals, not datetime format.
edit: further:
This is directly from the RFC this thread is about:
Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
Firstly, users tend to write them as 23:59:59 or even 23:59. When used as a query, this can skip a second or even a minute of data.
Secondly, 00:00:00.0000 can match the first moment of tomorrow, which may also be wrong, and happens readily when timestamped data is imported from systems with per-second granularity.
Finally, these forms constrain any internal representation, which cannot now ever evaluate to 23:59:59.99995 lest we suffer the same category of fault. This'd limit a standard library's timestamp object to a precision of 10μs, which is pretty coarse for many timing needs.
The proper form, that is, the ideal mathematical representation, is an interval with a closed left/lower bound and an open right/upper bound. That's written like
[00:00:00.0000, 00:00:00.000+1day) or equivalently
{ t | 00:00:00.0000 <= t < 00:00:00.0000+1day }
Some (sadly not all) programming languages have such a construct available in their standard library.
I think there's a paper by Lamport recommending this form, although I couldn't find it in a quick rummage through the archives.
Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
sure, your use case sounds valid. but that doesn't mean it needs to be part of the standard or implemented by everybody else. it's the sort of thing that should be implemented by the people who need it and that nobody else has to think about.
That does include the period definition format, which I know will disappoint some people.
You mean the milliseconds? You're correct that YMMV with regards to libraries, but a lot of them handle milliseconds as well.
2007-03-01T13:00:00Z/P1M
For something that occurs on the first of each month.
[1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
If you want to record a local timestamp historically (e.g. log that this event of the electric facility happened at this time in the history of the facility, at the location of the facility), you want to say exactly when it happened, in the local time of the place, notwithstanding political/societal changes to the timezone it is attached to.
Does this make sense? Talking about time always makes things confusing.
Maybe it's just historical baggage from not wanting to keep that historical record of time zones around for all eternity?
I dunno. It's a bit weird to me. It's a very indirect (precise) measure of something that doesn't seem like it would have much use over just recording the direct measure (TZ and/or just the UTC timestamp)
The more your learn about datetime the more confusing it gets, I suppose :). I guess it's good to know that it can get very confusing (and therefore to tread carefully) and to temper one's expectations of datetime libraries.