Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Navigating the timezone nightmare in product development

getlago.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Navigating the timezone nightmare in product development

#21

Post by midasuni »

treve wrote: post #3

Common mistake that I don't think the author got right either, is that if you want something to happen at a future local time time, say 2PM in São Paulo at some date next year, you don't use UTC + a timezone, you use local time + timezone. Timezones are not immutable, and timezone database updates happen every year. Only if you track dates that happen in the past UTC makes sense. In some cases/jurisdictions they chan…

https://mm.icann.org/pipermail/tz/2020-October/029376.html

For example - 5 days notice for a DST change.

Re: Navigating the timezone nightmare in product development

#22

Post by kodra »

cholindo wrote: post #10

> Time Zones often have a "friendly name" in the format Continent/City|Island Continent/City are not friendly names, they are political boundaries that gice more precision. For example, CET covers many countries that might decide to stop applying DST at different points in time. If you store CET in your database you won't know if you need to apply CEST or not. This is why you always need the Continent/City form if yo…

Political friendliness (n.)

Re: Navigating the timezone nightmare in product development

#23

Post by esafak »

marcosdumay wrote: post #16
esafak wrote: post #13

Earlier quoted context omitted.

Can off-the-shelf libraries translate from any Bizarro time to UTC?

Not in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.

So what do you do, record both the local time and UTC?

Re: Navigating the timezone nightmare in product development

#24

Post by Veserv »

Terr_ wrote: post #6
treve wrote: post #3

Common mistake that I don't think the author got right either, is that if you want something to happen at a future local time time, say 2PM in São Paulo at some date next year, you don't use UTC + a timezone, you use local time + timezone. Timezones are not immutable, and timezone database updates happen every year. Only if you track dates that happen in the past UTC makes sense. In some cases/jurisdictions they chan…

Yeah, I often like to emphasize that many "scheduled events" are not simple numbers, but pattern-matching conditions , a contract of triggering-rules for something an unknowable number of elapsed seconds from "now." To be specific, it's "whenever the desk-calendars and wall-clocks in that jurisdiction will say X because the local government says so." The government of Bizarro São Paulo could decide to pause the clock…

To elaborate further on your point, the key takeaway is that you can not, in general, predict what second a future date will occur because dates are societal and civil constructs meant for coordinating human activity.

Counterintuitively, this is not true for the past and present. A specific second is unique. As long as you know the second you can derive the exact date (in the past) it occurred in whatever civil time standard you are using. The past and present should always be stored in TAI. The future should usually be stored as “pattern-matching conditions” (though you can use TAI if you are recording a elapsed time/seconds until the event).

Re: Navigating the timezone nightmare in product development

#25

Post by vidanay »

midasuni wrote: post #18
vidanay wrote: post #7

Timezones are easy. All you need is a complete understanding of Special Relativity and inertial frames of reference. Bada bing, bada boom.

The relativity and frames of reference are trivial compared to the whims of international politics

God doesn't play dice, but random governing bodies sure do.

Re: Navigating the timezone nightmare in product development

#26

Post by squeaky-clean »

msla wrote: post #4

It's solved, in that I'm never going to do better than zoneinfo and I'm not going to go crazy trying. https://en.wikipedia.org/wiki/Tz_database https://www.iana.org/time-zones I think of this as "difficulty snap back": Things can only get so difficult before everyone punts and uses some external library.

The article isn't about implementing your own time zone handling directly. It's about incorrect assumptions you can make when using such a timezone database or library.

For example, carefully consider when events need to happen at a fixed time relative to server time (utc) vs user local time. Consider how you handle changes to the timezone database. A timezone change can cause the scheduled time of an event (such as billing) to not exist in that time zone, or for a scheduled time to occur twice. A user changing their timezone setting can cause a similar effect.

Re: Navigating the timezone nightmare in product development

#27

Post by beachy »

In our applicant tracking product, we had a close date by which candidates must apply for the job.

Early on there was a bug due to timezone handling where the job would close an hour too early.

No big deal one would think - the job is open for weeks, maybe months, so who cares if it closes at 11pm on the last day instead of midnight?

It turns out that a lot of people live their lives by the "last minute" principle. They want to do things at the very last minute, and they get furious when the last minute comes too soon.

Re: Navigating the timezone nightmare in product development

#28

Post by Veserv »

esafak wrote: post #23
marcosdumay wrote: post #16

Earlier quoted context omitted.

Not in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.

So what do you do, record both the local time and UTC?

You record a context sensitive date/condition based on the user intent (i.e. birthday travels with the user, in person meeting based on meeting location, international call based on local time or UTC, explicit timezone keeps the timezone, etc.). How you map user intent to recorded date is problem specific.

When the event happens you record the TAI. You may also wish to record the context sensitive date for auditing purposes, but it is not strictly necessary. You can rederive the occurred date if the event occurred in the past.

Re: Navigating the timezone nightmare in product development

#29

Post by Terr_ »

esafak wrote: post #23
marcosdumay wrote: post #16

Earlier quoted context omitted.

Not in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.

So what do you do, record both the local time and UTC?

IMO the way to avoid insanity is explicit modeling, the pain comes from where different code was written with different beliefs about what the value "really means."

For example, if there's a lunchtime event in Bizarro São Paulo you record "Noon in Bizarro Brazil Time" or even ("Noon in whatever timezone that office building will exist in") because it really does depend on the rhythm of the city. In contrast, if it's an international video-conference, you might record it as a time in UTC or the timezone/city of the most-critical participants.

In both cases, users of the system should be able to see the "contract" along with the predicted moment in a probably-useful local representation. (I might not be in Bizarro São Paulo while I'm looking at the event, but I might know I'll be flying there later...)

If you're afraid a Bizarro-govt is going to do something weird at the last second and cause all sorts of customer complaints for missed events, you might code a system that keeps track of when predicted-times (in something safer like UTC or TAI) suddenly change for events in a way that might catch users by surprise, and then send out notices.

Re: Navigating the timezone nightmare in product development

#30

Post by smokel »

Date and time handling in software is one of the most dramatic examples of software being a means of communication between humans and machines. What appears to be a seemingly basic physical process turns out to demand reams of code to manage leap years, leap seconds, time zones, the birth of Christ and that of Unix, Gregorian and Julian calendars, and worst of all: daylight saving time (DST).

DST was once supposed to save energy, but my own personal frustration with it alone could warm the Earth's atmosphere by a whole degree Celsius.

Post reply on HN