321–330 of 466 posts
I think the old Riyadh timezone is the weirdest personally https://github.com/eggert/tz/blob/be62d5918223b4df209cc94163...
> Btw it’s called UTC (Universal Time Coordinated? huh?) because the same folks who publish UTC also publish UT1, which is UTC sans the leap seconds. I’m not sure that’s right! According to legend among metrologists I’ve talked to, “UTC” was chosen as a compromise candidate: it makes sense as an acronym in neither English nor French.
Which is not an acronym, btw, it's just styled in all caps, and is to be pronounced "iso" rather than "eye-ess-oh".
Earlier quoted context omitted.
Only if everyone is a peasant farmer with the same crops in the same place. My activities are barely related to the height of the sun in the sky, and like the other residents of my city I don't take a ton of notice of harvest time. Bus timetables and cultural festivals are a much bigger deal (of which one in particular is indeed historically related to a harvest).
This "Day is 12 hours long" thing just doesn't work anywhere else. I live far from the equator - "Dawn" is sometimes after breakfast, and "Dusk" can happen before I get off work.
Then you get above the Arctic Circle, and there are days with neither. :D
A thousand years ago, every village had their own timekeeping and it worked. Our village is now earth. What if we just abandoned daylight-savings time and timezones and just went with GMT (or anything else) for everywhere on earth? There would be cultural effects as people in California now start work at 16:00, for example...
A thousand years ago, every village had their own timekeeping and it worked. Our village is now earth. What if we just abandoned daylight-savings time and timezones and just went with GMT (or anything else) for everywhere on earth? There would be cultural effects as people in California now start work at 16:00, for example...
The hard part is not doing it, it's getting people to agree. I highly doubt people will agree to do that, because a large portion of people don't agree with "our village is now Earth".
Excellent read around the acrobatics of timezone software. It really is quite flexible. It leads me to wonder. If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments. Couldn't a nation decide to have a continuously changing offset throughout the year? It might make their offset lookup table substantially longer, but this could 'solve' daylight…
The only really important assumption not obviously present in TZif's data format is that when you go from a local time to a UTC time, there can only be up to two possibilities. A lot of software works on that assumption, for instance java.time.LocalDateTime has a withLaterOffsetAtOverlap():
https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
That implicitly assumes that whenever it's ambiguous what 2:30AM means, you can only have two possible solutions (pre- and post-DST). If a timezone were ever to manipulate its offsets so that there were three or more solutions (such as if they did a "fall back" at 2:00AM and then 2:15AM or something), a lot of stuff would be unable to represent that.
A thousand years ago, every village had their own timekeeping and it worked. Our village is now earth. What if we just abandoned daylight-savings time and timezones and just went with GMT (or anything else) for everywhere on earth? There would be cultural effects as people in California now start work at 16:00, for example...
Everyone would create local time zones and use them. It is convenient to have the clock synchronized to the local day. Using UTC optimizes for long distances when people use local clocks much more often. How do you handle the date changing in the middle of the day? If I was on UTC, the date would change at 5pm. Is that still Wednesday or would it be Thursday? Also, it doesn't solve the problem since still need to fig…
It seems like you would have to do absolutely nothing? Just like you do absolutely nothing to "handle" the hour changing throughout the day. People work overnight shifts. People schedule important events close to and on either side of midnight.
Earlier quoted context omitted.
UTC is generally a good idea for storing, but there are still some ways to have that bite you. If a user enters a local date time for a future event in a particular time zone, converting that to UTC could result in incorrect behavior if the timezone definition changes. It depends on if the user meant that UTC time or if they meant the local time.
> if the timezone definition changes Or if DST kicks in/out. No need to have the definitions change.
I find it slightly ironic that a blog that’s educating (and entertaining) us on time and timezones does not itself mention when its blogposts were published, at least on mobile. This one appears to have been published in the summer of 2024.
I really love this way of writing. Informational with occasional bits of humor. It makes it read and ingest.