|
|
Subscribe / Log in / New account

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?

> There's no 24:00, or 24:anything.

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".


to post comments

A fork for the time-zone database?

Posted Oct 3, 2021 16:13 UTC (Sun) by marcH (subscriber, #57642) [Link] (4 responses)

> For example you can say "Open at 2011-02-28 from 16:00 to 24:00"

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"?

A fork for the time-zone database?

Posted Oct 3, 2021 17:15 UTC (Sun) by Jonno (subscriber, #49613) [Link] (3 responses)

>> 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"

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"
>Understood but I don't remember seeing that anywhere I've been.

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".

A fork for the time-zone database?

Posted Oct 3, 2021 18:29 UTC (Sun) by Wol (subscriber, #4433) [Link]

But, as I pointed out, it is apparently quite common for night shifts to be clocked as 22:00 - 32:00.

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,
Wol

A fork for the time-zone database?

Posted Oct 3, 2021 19:52 UTC (Sun) by perennialmind (guest, #45817) [Link] (1 responses)

When working with intervals, it's often desirable to establish a convention leaving one side open. With time, it's generally: start, inclusive and end, exclusive. With that view, noon falls unambiguously in the latter half of the day: pm.

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.

A fork for the time-zone database?

Posted Oct 3, 2021 20:10 UTC (Sun) by marcH (subscriber, #57642) [Link]

This just yet another problem of counting from 1 and not 0.

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.

https://en.wikipedia.org/wiki/Zero-based_numbering


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds