A fork for the time-zone database?

Posted Oct 2, 2021 19:53 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: A fork for the time-zone database? by intelfx
Parent article: A fork for the time-zone database?

As an American who trained myself to read 24-hour time, I actually ended up memorizing a series of mnemonics for it:

* 0:xx = 12:xx AM (just memorize)
* 1-11:xx = 1-11:xx AM (obvious)
* 12:xx = 12:xx PM (obvious once you have the first rule memorized)
* 13:xx = 1:xx PM (13 is not composite, neither is 1)
* 14:xx = 2:xx PM (14 is even)
* 15:xx = 3:xx PM (15 is divisible by 3)
* 16:xx = 4:xx PM (16 = 4²)
* 17:xx = 5:xx PM (17 and 5 are both prime)
* 18:xx = 6:xx PM (18 is divisible by 6)
* 19:xx = 7:xx PM (19 and 7 are both prime)
* 20:xx = 8:xx PM (20 and 8 are both divisible by 4)
* 21:xx = 9:xx PM (21 and 9 are both divisible by 3)
* 22:xx = 10:xx PM (22 and 10 are both even)
* 23:xx = 11:xx PM (23 and 11 are both prime)
* 24:xx doesn't exist. Some people write 24:00 to mean 0:00, but at the end of the day instead of the beginning of the day.

These mnemonics work largely because 12 is a highly composite number, and adding 12 to any given number doesn't change its divisibility by any factor of 12 (i.e. if x is divisible by some factor of 12, then so is x + 12). The primes, on the other hand, appear to arise for the opposite reason, which is that 12 covers nearly all of the available prime factors (i.e. if x is *not* divisible by some factor of 12, then neither is x + 12), and the few that it misses are just not dense enough to stop the shifted primes from existing.

A fork for the time-zone database?

Posted Oct 2, 2021 21:23 UTC (Sat) by rschroev (subscriber, #4164) [Link] (13 responses)

I must be missing something, but why not simply

* 0:xx = 12:xx AM (just memorize)
* 1-11:xx = 1-11:xx AM (obvious)
* 12:xx = 12:xx PM (obvious once you have the first rule memorized)
* everything else: subtract 12, put 'PM' after it

I don't think I understand why you would need to memorize anything (apart from the possible confusion with 12 AM/PM).

A fork for the time-zone database?

Posted Oct 3, 2021 0:11 UTC (Sun) by Wol (subscriber, #4433) [Link] (7 responses)

Yup. Ante/Post-Meridian ... the only confusion is what do you call the (Anti)Meridian. So all you need to do is remember both the morning and afternoon - for this purpose - START at 12 exactly.

You have the same problem with the 24-hr clock - is midnight 0:00 or 24:00? But it's the exact same rule - the day STARTS at midnight 0:00 exactly.

(Then, of course, you have all those weirdos where time-keeping applications apply the rule that a work shift always ends the same day it starts, so it would have had my hours as working from 22:00 to 32:00 ...)

Cheers,
Wol

A fork for the time-zone database?

Posted Oct 3, 2021 7:38 UTC (Sun) by marcH (subscriber, #57642) [Link] (6 responses)

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

A fork for the time-zone database?

Posted Oct 3, 2021 8:23 UTC (Sun) by Jonno (subscriber, #49613) [Link] (5 responses)

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

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

A fork for the time-zone database?

Posted Oct 3, 2021 4:34 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (4 responses)

Because mental arithmetic is hard and recognizing numerical patterns is easy.

A fork for the time-zone database?

Posted Oct 3, 2021 7:46 UTC (Sun) by marcH (subscriber, #57642) [Link] (1 responses)

Where I grew up people usually read aloud 18:00 as "six o'clock". It's read "eighteen o'clock" only when there's a lack of context and risk of confusion because it's a train schedule or something. So, all kids learn how to add 12 until they know the whole range by heart and none seems to be in need of any "easier" trick.

A fork for the time-zone database?

Posted Oct 4, 2021 22:10 UTC (Mon) by Wol (subscriber, #4433) [Link]

Some other poster commented on this, but to me a time "on the hour" in the 24-hr clock is always referred to as "hundred", ie "eighteen hundred". If there's any confusion as to whether time is meant, the word "hours" is added - "eighteen thirty hours". Noticeably, this is normally not used ante-meridian, just post-meridian :-)

Cheers,
Wol

A fork for the time-zone database?

Posted Oct 3, 2021 11:34 UTC (Sun) by rschroev (subscriber, #4164) [Link] (1 responses)

Interesting, you and I must have very different ideas about what is easy and what is difficult!

A fork for the time-zone database?

Posted Oct 3, 2021 12:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

As many do :) . As mentioned elsewhere, if my watch says "18:30", I'll answer "six thirty" if someone asks me the time. The way I think about is to "subtract 2" and ignore the tens digit when the number is "large enough". For 22:00 and later, the time of day is the hint that it isn't the earlier hours.