Also, some timezone labels are ambiguous, e.g. "CST".

pxx · 2024-10-08T02:54:16.000000Z

What I learned recently is the way Python strptime deals with this. It only parses the current time zone or "GMT" or "UTC" and all have the same effect (of returning a tz-naive object). This behavior is amazing because I don't think it's ever what you want.

$ TZ=Asia/Shanghai python -c "import datetime; print(datetime.datetime.strptime('4CST', '%H%Z').astimezone(datetime.timezone.utc))"

1899-12-31 19:54:17+00:00

$ TZ=America/Chicago python -c "import datetime; print(datetime.datetime.strptime('4CST', '%H%Z').astimezone(datetime.timezone.utc))"

1900-01-01 10:00:00+00:00

$ TZ=America/Havana python -c "import datetime; print(datetime.datetime.strptime('4CST', '%H%Z').astimezone(datetime.timezone.utc))"

1900-01-01 09:29:36+00:00

$ TZ=America/Havana python -c "import datetime; print(datetime.datetime.strptime('4CDT', '%H%Z').astimezone(datetime.timezone.utc))"

1900-01-01 09:29:36+00:00

$ TZ=America/Los_Angeles python -c "import datetime; print(datetime.datetime.strptime('4CST', '%H%Z').astimezone(datetime.timezone.utc))"

ValueError: time data '4CST' does not match format '%H%Z'

That last error was real fun to debug when something worked in production but not locally.

OhMeadhbh · 2024-10-08T01:07:11.000000Z

How is CST ambiguous? Are you thinking of all those counties in Indiana that don't observe daylight savings? In theory at least, a specific instant in CST maps to a single specific instant in UTC, GMT, CUT or Zulu Time, whichever you set your watch to.

And it does seem like people sometimes forget that CST is not the same thing as CDT. Several months ago (after the 2024 PST -> PDT crossover) I had someone across town tell me they wanted to set up a meeting at something like 9AM. But when the invite came, the time zone was set for 9AM PST instead of 9AM PDT. I assumed it was PDT since we were in the same locality. But I did make sure my schedule was clear for the hour before on the off chance they had some weird software bug that picked time zones at random.

If your point is something similar, then I heartily agree. In theory, converting between time-zones and daylight and standard times is easy, but in practice there are several situations where it's made more difficult than it should be.

quesera · 2024-10-08T14:37:21.000000Z

I was referring to the multiple timezones that are abbreviated to "CST", as described in a sibling comment.

But you bring up another good example. I've worked with people who write times as "PST" or "EST" all year long. This bothers me in its simple incorrectness -- I do know what they mean but I hate autocorrecting them.

But I've also worked with people in parts of Indiana, and Mexico. When they say "CST" at any time of the year, they might mean it precisely!

My strategy is to write, e.g. "8:30 AM US/Pacific". Which probably annoys other people, but at least it's precise and unambiguous. I think it's less awkward than the equivalent "America/Los_Angeles".

Full list of US lower 48 timezones: US/Arizona, US/Central, US/East-Indiana, US/Eastern, US/Indiana-Starke, US/Michigan, US/Mountain, US/Pacific.

And the +2s: US/Alaska, US/Aleutian, US/Hawaii

chucksmash · 2024-10-08T01:40:12.000000Z

> How is CST ambiguous?

- CST: Central Standard Time UTC−06

- CST: China Standard Time UTC+08

- CST: Cuba Standard Time UTC−05