A fork for the time-zone database?
A fork for the time-zone database?
Posted Oct 3, 2021 8:23 UTC (Sun) by Jonno (subscriber, #49613)In reply to: A fork for the time-zone database? by marcH
Parent article: A fork for the time-zone database?
Actually there is a 24:00:00.000, but not 24:anything-else. This is so you can describe the end of a day without involving the next date. For example 2011-02-28T24:00:00.000 equals 2011-03-01T00:00:00.000 exactly.
This is especially convenient for time durations ending at midnight. For example you can say "Open at 2011-02-28 from 16:00 to 24:00" instead of "Open from 2011-02-28 16:00 to 2011-03-01 00:00".
Posted Oct 3, 2021 16:13 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (4 responses)
Understood but I don't remember seeing that anywhere I've been.
> Actually there is a 24:00:00.000, but not 24:anything-else. This is so you can describe the end of a day without involving the next date.
So how does that help "from 16:00 to 00:30"?
Posted Oct 3, 2021 17:15 UTC (Sun)
by Jonno (subscriber, #49613)
[Link] (3 responses)
It doesn't. But in that case you are actually open during two different calendar days, so it is natural that you need two different dates to unambiguously describe the period of time in question. But if you close at midnight, you are only open during one calendar day, so the need to use two different dates for the opening and closing time would be awkward, thus the 24:00 special case.
( BTW, the same is true of some am/pm usages, where "12:00 am" is equivalent to "00:00", "12:00 noon" is equivalent to "12:00" and "12:00 pm" is equivalent to "24:00". Of course, in other am/pm usages "12:00 am" ambiguously refer to midnight at either the start or the end of the day, while "12:00 pm" refer to noon; and in yet other am/pm usages "12:00 am" refer to "noon", while "12:00 pm" ambiguously refer to midnight at either the start or the end of the day. Neither of these usages makes sense if you consider the literal meaning of am (ante meridiem - before noon) and pm (post meridiem - after noon): at noon it is neither before noon nor after noon, so both am and pm are incorrect, while at midnight it is equally after one noon and before another noon, so either am or pm can be equally correct, depending on which noon you are referring to. Even so, both the later two versions are more common than the first. Most computer systems consider "12:00 pm" to be noon, but before the age of computers using "12:00 am" for noon was clearly the most common usage... )
>> For example you can say "Open at 2011-02-28 from 16:00 to 24:00"
It's fairly uncommon for places to close at midnight, as most "normal" businesses close earlier and most "nightlife" establishments close later, but in the rare cases someone actually closes at midnight, I have only ever seen opening hours listed as "16:00 - 24:00", never as "16:00 - 00:00".
Posted Oct 3, 2021 18:29 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Clearly unambiguous for anything that is expecting it ... :-) and gets round the problem of special-casing shifts that finish before they start ... at the cost of having to handle shifts that end after the normal end of the day.
Cheers,
Posted Oct 3, 2021 19:52 UTC (Sun)
by perennialmind (guest, #45817)
[Link] (1 responses)
The best I can say in defense of the clock's modulo-12 residue starting system at 1 is that it's not technically wrong, merely suboptimal.
Posted Oct 3, 2021 20:10 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
There would be no am/pm inconsistency if 12h clocks counted from 0:
0:00am 1:00am ... 11:00am 0:00pm 1:00pm ... 11:00pm
When the zero was invented, tens and hundreds and thousands started from 0 but units kept starting at 1 for obvious "backward compatibility" reasons. This is the root cause of many inconsistencies and why 24h clocks and most programming languages switched to counting from zero.
A fork for the time-zone database?
A fork for the time-zone database?
> So how does that help "from 16:00 to 00:30"
>Understood but I don't remember seeing that anywhere I've been.
A fork for the time-zone database?
Wol
A fork for the time-zone database?
A fork for the time-zone database?