Is AWS S3 having an outage?

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.

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

All times on the page are in UTC and are wrapped in a <time> element. The raw UTC time is on the datetime attribute and a fallback more easily readable time is inside the tags. Some JS on the page removes whatever text is inside the tag and replaces it with the user's locale specific format (no libraries required, it's a part of the browser standards).

User friendly times wasn't actually the reason we implemented it.

Our largest concern was our E2E testing. We needed to make sure that the dates/times displayed were always right (and since subscriptions involve money, we wanted to make sure that part of the website was the most tested.) The E2E testing simply ignores whatever is inside the tag and reads the datetime attribute instead. Then we can fastforward or rewind the simulated time inside the test to make sure everything is working as expected.