A fork for the time-zone database?

Posted Sep 30, 2021 17:08 UTC (Thu) by amacater (subscriber, #790)
In reply to: A fork for the time-zone database? by marcH
Parent article: A fork for the time-zone database?

Switch the server to GMT is the answer - everything else then becomes a local offset and logs are consistent no matter where you read them from.

This is how the military keep time. [Flying as a civilian with the RAF - "Do you want UK time, Hong Kong time, local time on the ground or RAF time?"] - the pilots keep one timezone wherever they fly in the world and eat/sleep etc. accordingly. The only oddity, done for log keeping purposes is that 2359 leads seamlessly to 0001 so that there is never an ambiguity as to date. Seasoned Services folk claim that the odd few seconds are "your time" in the day.

A fork for the time-zone database?

Posted Sep 30, 2021 17:25 UTC (Thu) by Wol (subscriber, #4433) [Link]

I like reading WW2 autobiographies, and I remember one escort commander complaining about a ship under his command ... iirc the Captain operated "ship's time" which was GMT+2. Seeing as the rest of the flotilla kept local time on the transatlantic run, the Commander was moaning that he had to remember what the time was on this ship, as he'd get reactions like "can't a chap have his afternoon nap in peace?" ... early in the morning!

Cheers,
Wol

A fork for the time-zone database?

Posted Sep 30, 2021 23:29 UTC (Thu) by marcH (subscriber, #57642) [Link] (18 responses)

It makes me smile every time someone in the US looks at some 24h clock of mine and tells me "oh, you're using military time?". No, just time.

This sequence is also very funny: 10am, 11am, 12pm(!), 1pm, 2pm

But what _really_ cracks me up is when people read "military time" aloud. Example:

16:21 = sixteen HUNDREDS (!!) twenty one

Remember this is in the country where nothing is DECIMAL but a happy mix of units in base 4, base 12 and what not instead. So the only unit where base 10 sort of made it is actually https://en.wikipedia.org/wiki/Sexagesimal! Hilarious.

A fork for the time-zone database?

Posted Oct 1, 2021 9:27 UTC (Fri) by excors (subscriber, #95769) [Link] (17 responses)

> This sequence is also very funny: 10am, 11am, 12pm(!), 1pm, 2pm

Seems quite logical to me, since time is a continuous value:

11:59:59.999 - before midday, so definitely "am" (ante meridiem)
12:00:00.000 precisely - ???
12:00:00.001 - after midday, so definitely "pm" (post meridiem)

The (sensible) convention is for midday precisely to be called "pm", which means the label changes at the same point that the numbers roll over, and you avoid having an infinitesimal period where it's 12 but still "am". Then you can easily truncate any "hh:mm:ss.sss" down to "hh:mm:ss" or "hh:mm" or "hh" without having to worry about crossing the threshold where the label changes.

On the other hand, I'll agree that 12 o'clock really should be 0 o'clock.

A fork for the time-zone database?

Posted Oct 2, 2021 5:43 UTC (Sat) by jezuch (subscriber, #52988) [Link]

Kinda. But it always gives me, a European, a pause. "Wait, is this meeting at midnight? No, that's silly, it must be this confusing notation for noon".

A fork for the time-zone database?

Posted Oct 2, 2021 18:02 UTC (Sat) by intelfx (subscriber, #130118) [Link] (15 responses)

Not so much logical if you grew up using 24-hour notation and your brain wired itself up to understand "pm" as an offset (i. e. "am" is equivalent to "+0", and "pm" equivalent to "+12"). Then it goes like this:

- "10am" = 10+0 = 10
- "11am" = 11+0 = 11
- "12pm" = 12+12 = 24 --- wtf?
- "1pm" = 1+12 = 13

Like most other things, it's a matter of perspective. I trip over this notation constantly.

A fork for the time-zone database?

Posted Oct 2, 2021 19:53 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (14 responses)

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.