Australia/Lord_Howe is the weirdest timezone

Post by psychoslave » Thu, Oct 31, 2024, 10:46 AM UTC

dpassens wrote: post #64

tankenmate wrote: post #60

Earlier quoted context omitted.

The decision to not support it isn't "arbitrary" per se; it's a function of utility vs cost to implement (which a healthy dose of fudge). "Standard software" for timekeeping is far more useful precisely because it is used by far more people.

Maybe arbitrary was the wrong word. I understand that this is an implementation cost issue and I'm not saying that the decision not to pay this cost wasn't reasonable. My objection is not with tzdb, but with the characterisation of a real-life practice as weird just because software doesn't accommodate it. Shouldn't what people do be the reference for what is normal, rather than the rules encoded in software?

Post by andix » Thu, Oct 31, 2024, 10:55 AM UTC

IgorPartola wrote: post #149

I know this is a popular sentiment here but it bears repeating: timezones need to go away. Time according to timezones measures the position of the sun. Except when we clearly decide with daylight savings time that we don’t care about the position of the sun, we just want it to be a certain time. When the sun is directly over NYC it is usually 1pm or 2pm, depending on time of year, but 5pm or 6pm in London. Why? Are…

Post by psychoslave » Thu, Oct 31, 2024, 11:14 AM UTC

mywittyname wrote: post #243

Buttons840 wrote: post #191

Earlier quoted context omitted.

Moving up and down at a linear rate would result in a saw-tooth-like wave, but the length of days change in a sine wave. Why not have the clocks sync themselves to sunrise time based on their timezone and latitude? I don't think this would be much different, in practice, than changing times at a linear rate.

This would lead to a monumental amount of confusion. The primary time keeping device in my house is the clock on my stove; I wear old school watches a lot; and most of my cars are old and have old clocks in them. I can't be the only one, so multiply this by at least a few million other people in America alone. Sure, you can tell everyone they need to ditch dumb clocks and replace them with internet-enabled smart cloc…

Post by Vampiero » Thu, Oct 31, 2024, 1:56 PM UTC

poincaredisk wrote: post #406

ianburrell wrote: post #290

Earlier quoted context omitted.

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 is convenient to have the clock synchronized to the local day Is it really, or are we just used to it? This seems to be busy a random reference frame. I, for example, am an extreme night owl, and often go to sleep at 5am or later. So, to me, 12:00 is very far from the middle of the day (in fact, sometimes I'm still asleep at that time). This desync doesn't cause any problems for me.

Post by maxwell » Thu, Oct 31, 2024, 2:20 PM UTC

schoen wrote: post #414

maxwell wrote: post #302

Earlier quoted context omitted.

UTC is problematic since it splits the day: when it's midnight in Greenwich, it's still yesterday for half the world. The Unix epoch occurred in 1969 in Hawaii. BIT (UTC-12) is better. Only positive offsets. Everyone on the same day.

Don't you get the "it's already tomorrow for half the world" problem in place of the "it's still yesterday for half the world"?