So? I'd be happy if people would consistently use RFC 3339 (https://tools.ietf.org/html/rfc3339). This will solve 99.999% you're going to run across. If you're part of that 0.001% who actually needs the standard - then it will be worth a few bucks to obtain it.
In my experience when people refer to ISO-8601, they generally mean RFC 3339 instead anyway.
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 my experience (as a European) I found that RFC3339 was lacking a few things when it comes to software development;
especially the usage of 24:00 to mark midnight at the end of a day;
which is a valid value according to ISO8601(can't remember the section).
I work for a utility who often needs to work with interval data. The last interval of the day is 23:00-24:00 whereas the first interval of the day is 00:00-01:00. Some libraries can handle that as you'd expect, others can't. A lot of people are surprised to see 24:00. The key is 24:00 is the same date as 23:00, whereas 00:00 is the next day. It sounds like you have a similar need?
In railway timetables things like 24:37 are sometimes used, for example for a train that leaves at 23:45 and arrives at 24:37 on weekdays. It would not just be confusing but totally incorrect to claim that the train arrives at 00:37 on weekdays. On the other hand, I don't think I've ever seen a 25:xx, and if you were writing a timetable for a slow train on the Trans-Siberian Railway then I really don't think people would appreciate it if you used a three-digit hour.
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".
Times greater than 24:00 are not allowed by ISO 8601.
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.
How would that be "totally incorrect"? There are only 24 hours in a day. It's incorrect to claim that there's 25, 26 or 27 hours in the day - even if it's useful and proper, it's not technically correct.
I'm making a guess here, but I think he means specifically the (A) "arrives every weekday at 00:37" part. That has a different implied meaning than (B) "the train arrives every weekday at 24:37." (A) implies that it will arrive every Monday through Friday mornings at 00:37 but will not arrive on Saturday or Sunday mornings at 00:37. (B) implies that it will arrive Tuesday through Saturday mornings at 00:37, but not Sunday or Monday mornings.
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.
right - 24:37 friday makes is read as "37 past midnight on friday night" - which is friday night as humans consume time, but saturday morning by the calendar.
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.
An app I have to track habits and streaks lets you specify the time to count as "that day". I often walk my dog after midnight, so I have this set to 3am.
Think of it as a 24 hour day that starts at (to use UK public transport's setup) 4:30. You want the timetable and the users to agree on what 8am means, and that 8am and the following 2am are the same work day of 24 hours.
Google's GTFS spec, which is a spec for defining transit schedules among other things, allows for times greater than 24:00:00 to represent arrival and departure times on the following day for a given transit schedule.
I did have to use 25:xx to log some late nights working at my last job in Japan. It was very weird to me, but that's how they wanted it. If it was part of the current workday, then it wouldn't reset to 0:00.
Yep - we needed the distinction for a scheduling/rota app.
Some users had shifts that started at 24:00 and then ended sometime during the night. Other users had shifts that ended at 24:00.
I know that it's common to use 23:59 in the latter case, but IMO that's just a poor workaround; and I'd argue that 16:00 -> 00:00 is a lot less obvious than 16:00 -> 24:00.
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.
When I used to work in a 24/7 environment I would quip that "it's not tomorrow until the morning crew takes over." In a lot of practical situations I think it's easier for people to think about the early morning hours as being late the previous day. It tends to match shifts and reporting cycles better.
It's not tomorrow until I've been to sleep. It's not the morning until I've had a cup of coffee. Time is incredibly subjective. Clocks need to agree, but nomenclature does not.
I had a software project where I thought I could infer which shift was working from the time (because shift-related metrics were really important). I learned very quickly that shift and time, though related, are really separate data points.
Part of the problem is that midnight doesn't have a date. But we pretend it does because that's much easier to program. Similarly, noon is neither A.M. nor P.M. but we pretend it is P.M. because that's easier to program. Both cases were very understandable compromises in the early days of computing but now we have both the processing power and storage to do things correctly but because of legacy inertia, we'll keep on going pretending things that aren't true are true.
In practice the intervals don't overlap as they're understood as follows [23:00-24:00) and [00:00-01:00). That is the interval begins precisely at 23:00 or 00:00, but ends as close to the endpoint as your timing resolution allows. This way we don't have to write cumbersome expressions such as 23:00-23:59:59.999.
as a software developer who is constantly frustrated by ambiguous and confusing datetime representations, i'm really glad that your 24:00 display isn't in the spec. that's exactly the sort of thing that leads to bloated specs and programmers complaining about what a PITA dates are.
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.
Personally I think that supporting 24:00 is the wrong way to go. 23:59:59.9999 or <next day> 00:00:00.0000 should suffice in any situation I can think of. It's just a case of being overly fanciful, wanting 24:00.
The problems with 23:59:59.9999 etc are aliasing and granularity issues, i.e. breaks and overlaps when used as intervals or inequalities, and the consequences may be anything from innocuous (calendar alarms) to catastrophic (financial reporting).
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 }
and can be pronounced "all times from and including midnight onwards, until (but strictly excluding) midnight the next day". These half-open intervals correspond advantageously to the continuously linear assumptions of chronometric time, with two properties of critical relevance: they can be recorded via commonplace machine representations of timestamps; and, they may be compared, subdivided, and concatenated without inadvertent breaks and overlaps. These qualities eliminate most aliasing & granularity concerns.
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.
Sure, but just because it skips out on practical considerations, doesn't mean the RFC is irrelevant. The standard format is still helpful even if the semantics are underspecified.
Yeah, there's enough software that only understands ISO-8601 to be YYYY-MM-DDThh:mm:ss (with optional Z or +/-xx:xx for a offset datetime), that I wouldn't rely on anything more niche from the spec.
That does include the period definition format, which I know will disappoint some people.
After learning some more about the practicalities of time/date throughout my career, it always seemed a bit odd to me to even support the +/- thing... but maybe I'm missing something. My reasoning is: If it's a timestamp (i.e. it's a point on the physical time line, relativity notwithstanding), Z should be fine and unambiguous. If it's a local date/time then you need the actual legal time zone (e.g. Europe/Berlin, or whatever.) since those can and have changed historically. Sure, you can encode that as an offset for any given instant if you're actually talking about "now" or the past, but that's a lossy encoding and you can't really talk about future events using an offset.
My understanding is that it is because it changes historically that you'd rather want +/- (an absolute measure) rather than Continent/Location denonimation (a measure that is bound to change).
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.
Right, for explicitly recording a timestamp without having to refer to a historical time zone database it would seem to make a tiny bit of sense... but recording the actual time zone would work just as well for historical data and future times. I just have a hard time imagining a scenario where you really care about the offset... the timestamp itself is enough.
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.
Oh - combining a date/timestamp and a duration, such as xsd:duration (http://www.datypic.com/sc/xsd/t-xsd_duration.html). I've never seen them combined into a single string, though there have been times when that would have been really useful!
It looks like xsd:duration uses duration notation from ISO8601. The rules for combining them or designating recurring intervals are in ISO8601 section 4.4-4.5 [1]. Unfortunately, awareness and library support for ISO8601 interval notation are very sparse and most people/orgs just roll their own.
