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

51–60 of 65 posts

Re: Navigating the timezone nightmare in product development

#51

Post by x-complexity »

1) Outsource the nightmare to a 3rd party / open source library, whenever & wherever you can.

2) All events will trigger at UTC+0 time. Notify users on expiring events 24 hours before the event is triggered. Specify in contracts & EULAs that all events will occur on UTC+0 time.

3) "Soft expiry / leniency periods", wherein X amount of time is given after the event trigger in the "rare" cases where customers are late to respond to events. Do be warned though that customers will eventually treat this leniency period as if the expiry didn't happen, and some will inevitably complain when they can't do Y because they delayed well past the leniency period.

Re: Navigating the timezone nightmare in product development

#52

Post by takinola »

I built a logistics SaaS for ecommerce and the issue of timezones almost drove me insane. Finally, I discovered the 3-step solution to preserve my sanity.

1. Store all dates/times in UTC. This way, you know at least know exactly what point in time the data represents.

2. Display in the user timezone as needed

3. Delegate handling of time manipulation to an external library (like Lumen). This way you don't have to deal with all the intricacies of understanding international law and geopolitics required to turn timestamps into actual real life event

Re: Navigating the timezone nightmare in product development

#53

Post by pests »

ucarion wrote: post #47

> 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 durin…

There is a lot of interesting history in that file.

Re: Navigating the timezone nightmare in product development

#54

Post by cholindo »

midasuni wrote: post #15
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…

Time in the U.K. is europe/london. It’s entirely possible in the future that outlying Scottish islands may decide to keep DST while the rest of the country goes to year round daylight saving. You can’t always be future proof.

good to know, thanks

Re: Navigating the timezone nightmare in product development

#55

Post by himinlomax »

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…

Many problems would be solved by using TAI for storage instead of timezones/UTC. At least for past events.

Re: Navigating the timezone nightmare in product development

#56

Post by Macha »

sesm wrote: post #48
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 alway…

I think in most systems, calendar is called LocalDate and Wallclock is either LocalTime or combined with a LocalDate into a LocalDateTime.

Re: Navigating the timezone nightmare in product development

#57

Post by [deleted] »

himinlomax wrote: post #55
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…

Many problems would be solved by using TAI for storage instead of timezones/UTC. At least for past events.

[deleted]

Re: Navigating the timezone nightmare in product development

#58

Post by PlunderBunny »

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.

If it was a burn, it was pretty hot.

Re: Navigating the timezone nightmare in product development

#59

Post by Rafsark »

sigwinch28 wrote: post #2

This is a topic I often see overlooked from the user perspective and I'm happy to see more discussion about this. My anecdote: when I was working for a B2C startup we had to ensure we billed customers on the correct date, like OP. Timezones are hard; dates are easy (or so we thought). When we billed a customer on their billing date we had to attempt to take payment at a time , which meant that our naive date handling…

Completely true. I think the main point of your comment is about "presenting that information contextually to customers". You often have to make choices when you decide to bill your customers, and those choices have to be crystal-clear to your end users. When I was working for a neo-bank, 50% of the complains was about billing not being clear, and timezones was one of the top reasons.

Re: Navigating the timezone nightmare in product development

#60

Post by Rafsark »

Denvercoder9 wrote: post #33
sigwinch28 wrote: post #2

This is a topic I often see overlooked from the user perspective and I'm happy to see more discussion about this. My anecdote: when I was working for a B2C startup we had to ensure we billed customers on the correct date, like OP. Timezones are hard; dates are easy (or so we thought). When we billed a customer on their billing date we had to attempt to take payment at a time , which meant that our naive date handling…

The thing with dates depends on the context though. A birthday for example isn't associated with a timezone.

That's true, but wishing a birthday at the right moment depends on the timezone. It's not just about the date itself, it's about the interactions other people have with this date
Post reply on HN