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

41–50 of 65 posts

Re: Navigating the timezone nightmare in product development

#41

Post by tshaddox »

beachy wrote: post #27

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. T…

It's silly to demean the people who did that. You were the one that defined the existence of a "last minute we will accept applications," not those people. If you had wanted everyone to submit applications an hour before that time, you should have defined that to be the last minute (and then not demeaned people who submitted in that last minute). There's either a last minute you will accept applications, or there isn't!

Re: Navigating the timezone nightmare in product development

#42

Post by [deleted] »

tshaddox wrote: post #39
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…

I think this case is sufficiently complicated that we can't simply declare that the author got this wrong and that you should always use local time + timezone. What if that local time zone changes its DST rules to completely skip over that 2pm? Can we really confidently say that the user's intention when scheduling that event was that the event should be skipped if such a time zone change occurs between now and then?

[deleted]

Re: Navigating the timezone nightmare in product development

#43

Post by paulddraper »

smokel wrote: post #30

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 the planet, remove daylight saving

Re: Navigating the timezone nightmare in product development

#44

Post by GuB-42 »

smokel wrote: post #30

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…

I remember having a bit of fun computing the number of work hours between two dates.

It involved:

- the day of the week (office closed on weekends)

- day of the year, with leap years (office closed during holidays)

- Easter day (some holidays are based on Easter)

- DST and timezones (office hours are in local time, timestamps are UTC)

Thankfully, no Julian calendar or leap seconds to deal with.

Re: Navigating the timezone nightmare in product development

#46

Post by fjfuvucucuc »

hrrsn wrote: post #38
squeaky-clean wrote: post #8

Earlier quoted context omitted.

Another detail about dates people often forget or don't know (though it's not usually important), is that a "date" can be 50 hours long. Let's say you want to have some sale to occur all day on Christmas, midnight to midnight in your customer's local time. For easier math let's say your business is in GMT tz. People in the Line Islands (Pacific/Kiritimati) will have access to the sale 14 hours before yourself. Then t…

> the UTC+12 timezone is completely uninhabited New Zealand would like a word.

[dead]

Re: Navigating the timezone nightmare in product development

#47

Post by ucarion »

> And another fun fact (We had a lot of fun!): Time Zones often have a "friendly name" in the format Continent/City|Island except for UTC and... GMT+12, which only covers two uninhabited American islands :D

There's quite a few other non-slash-having names out there:

    ls -pL /usr/share/zoneinfo | grep -v '/'
"Eire" is in there, for instance, to deal with software that assumes that the "is_dst" half of the year is during the (northern) summer, but Ireland technically does it the other way around -- a distinction relevant only to computers.

https://github.com/eggert/tz/blob/c3e966c59b02b1f47f0b7b0e4a...

The only other timezone that currently has a non-1h offset for DST -- Ireland's is -1 hours -- is Australia/Lord_Howe, which has a 30-min positive leap.

Edit: there are also tzdb entries of the form "a/b/c" -- America/Kentucky/Louisville --- though they are not commonly used in practice.

Re: Navigating the timezone nightmare in product development

#48

Post by sesm »

smokel wrote: post #30

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…

Most of confusion can be resolved by introducing 3 separate entities (and naming them properly):

- Instant - a point in monotonously increasing time (Unix timestamp is usually a good enough approximation for most cases)

- Calendar

- Wallclock - non-monotonous human-readable clock

Being precise about which entity is used is enough to resolve most of the confusions.

For example, scheduling a doctor appointment is always Calender + Wallclock in a location of doctor's office. No Instant should be used to record this, and changing of DST rules for this location shouldn't affect the appointment. DST rules only matter if we want to convert from one Calendar and Wallclock to the other, then Instant may be used internally in calculations.

Back to the article: if we are talking about subscriptions, then we should specify, if subscription is valid for time interval of 365*24*60*60 seconds or the expiry is tied to Calendar+Wallclock, but in this case Calendar+Wallclock should have a specific location. The first option is much easier to implement, and to avoid any timezone/DST frustration adding an extra day of subscription (366 instead of 365) will be enough.

Re: Navigating the timezone nightmare in product development

#49

Post by scatters »

Terr_ wrote: post #29
esafak wrote: post #23

Earlier quoted context omitted.

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…

But also "whatever timezone that office building will exist in" may not actually be the same as the timezone that is actually used by the occupants of that office building. There are numerous communities which unofficially observe a different timezone to the one officially assigned to their locality.

Re: Navigating the timezone nightmare in product development

#50

Post by bradknowles »

midasuni wrote: post #17
throw-ru-938 wrote: post #14

Earlier quoted context omitted.

And when you interact with people 8 time zones away, concepts like "today" or "tomorrow" break down completely . It's a very uncanny feeling.

I remember having a call with two colleagues once, I was in Sydney, one colleague was in london and one in LA It was quite surreal, although time wise I think the LA person was up early on Tuesday and I was up late.

On the project I'm on now, we have regular weekly meetings like that. One guy in the UK, one guy in the DC area, me in Texas, another guy in Seattle, and another guy in Sydney. Plus possibly some other people that might also join from some of those same timezones.

I now have an app that runs continuously in my menu bar to track all the different time zones that I care about. Tel Aviv and Tokyo also figure into the equation sometimes.

Post reply on HN