7 ms·

Navigating the timezone nightmare in product development

53 points by dom_fr 3y ago

sigwinch28 3y ago
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 converted that date into midnight UTC on that date, causing many western European customers to be billed at 23:00 or earlier on the previous day from their perspective. Furthermore, from the operations side we were often dealing things that happened "on a date". I was pushing for at least our internal customer service systems to present two timestamps to agents: the date and time at which the thing occurred in the place that event occurred and also the date and time at which the thing occurred in the customer's location. For example, something being changed about a customer's account at 23:55 in London on a Monday actually happened at 00:55 on Tuesday for the customer in France. However, the timezone information was either not stored or not presented, interfaces were not consistent, and the result was pot luck whether the customer or a member of the customer service team would see Monday or Tuesday. Timezones are hard. Presenting that information in a contextually appropriate way to your own employees and customers can be just as hard. I like that the authors of the article have reached similar conclusions, especially around "dates have timezones". I think datetime capture and presentation is a fantastic UX topic.
- squeaky-clean 3y ago
  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 the sale-time occurs in GMT, 24 hours pass, and the sale ends in GMT. But people in American Somoa (Pacific/Midway) will still have the sale active for 11 hours. (Technically someone using satellite internet in the open ocean east of Samoa has 12 hours, but the UTC+12 timezone is completely uninhabited). Such a sale is kind of a farfetched example, but I've encountered this issue when trying to do analytics reports looking at user data that happens on specific global holidays.
  - throw-ru-938 3y ago
    And when you interact with people 8 time zones away, concepts like "today" or "tomorrow" break down completely. It's a very uncanny feeling.
    - midasuni 3y ago
      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.
      - squeaky-clean 3y ago
        One member of my D&D group moved to Denmark, one moved to Tokyo. The rest of us are on the US east coast. We have the hang of it now, but for our first few online sessions there was always someone who missed it because they showed up a full day late or early. It's also funny how some of the group is having coffee and breakfast while other members are getting drunk and having midnight snacks.
      - bradknowles 3y ago
        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.
  - hrrsn 3y ago
    > the UTC+12 timezone is completely uninhabited New Zealand would like a word.
    - fjfuvucucuc 3y ago
      [dead]
- Denvercoder9 3y ago
  The thing with dates depends on the context though. A birthday for example isn't associated with a timezone.
  - Rafsark 3y ago
    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
- coldcode 3y ago
  When I worked at an online travel agency building our iOS app, dates were a giant pain in the ass. What is today? What is tomorrow? I covered it at https://thecodist.com/what_time_is_tomorrow_tales_from_the_time_zone/ https://thecodist.com/what_time_is_tomorrow_tales_from_the_t...
- Rafsark 3y ago
  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.
treve 3y ago
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 change DST quite late so you'll only know with certainty what UTC time corresponds with what local time a few weeks in advance.
- Terr_ 3y ago
  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 clocks at 1:00PM, wait for one sunset and one sunrise, then set their clocks to 12:00PM, and then advance it by one "minute" every time a rooster crows until it reaches 12:10pm at which point they skip straight to 3:00pm. When is your schedule your 2PM wall-clock meeting? Probably around the tenth rooster-crow. If you had reason to distrust the clock-culture of Bizarro São Paulo, you shoulda made it a different timezone. :P
  - esafak 3y ago
    Can off-the-shelf libraries translate from any Bizarro time to UTC?
    - marcosdumay 3y ago
      Not in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.
      - esafak 3y ago
        So what do you do, record both the local time and UTC?
msla 3y ago
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://en.wikipedia.org/wiki/Tz_database https://www.iana.org/time-zones 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.
- squeaky-clean 3y ago
  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.
- Rafsark 3y ago
  Timezones are not hard to build. It's indeed the interpretation of your app and the display to your end users that are hard to manage. Think of your birthday: it's not hard for you to set a datetime at your current location to define when your birthday starts. But the birthday wished from your friends might changed based on the interpretation they have and where they are located
codetrotter 3y ago
I recently joined a small online forum from my country. They had some people write the whole thing from scratch more or less. I happen to be traveling currently. When I log into the forum from my location, which is one hour away time zone wise from the country the forum is from, and I make a post, I then see the timestamp for my own post presented as “in 59 minutes”. I reported the bug, but they didn’t fix it yet. I still find it hilarious. I happen to know that the owner of the forum is planning to go abroad sometime in January. If he does he will surely see this weirdness himself firsthand when he posts to his forum. Maybe then, once he gets to see it himself, a fix will be prioritised :p
- Rafsark 3y ago
  What would you expect as a fix? How do they know about the timezone you are currently on? Not an easy fix in my opinion as they have to be aware of your timezone (or ask for it) anytime you post
  - codetrotter 3y ago
    They are rendering the timestamp with JS. JS has the ability to see system time zone offset. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... It’s not difficult to send the time zone in UTC, and convert it client side to local time zone. And since they do “x minutes ago” kind of things they are certainly using a library. They are probably passing in “naive” timestamps without TZ info into a library that is perfectly able to handle it correctly for them, had they just read the docs for the library they used and taken a moment to make sure that they include TZ info. And if everything was done server side it would likewise be similarly easy to get it right because then my own time zone does not matter.
vidanay 3y ago
Timezones are easy. All you need is a complete understanding of Special Relativity and inertial frames of reference. Bada bing, bada boom.
- midasuni 3y ago
  The relativity and frames of reference are trivial compared to the whims of international politics
  - vidanay 3y ago
    God doesn't play dice, but random governing bodies sure do.
iso8601ca 3y ago
[dead]
mschuster91 3y ago
Now if AWS would learn that lesson as well... for example, AWS Backup Plans or CloudWatch Events always run in UTC, and there's nothing I hate more than doing timezone math - and on top of that, at least for CloudWatch Events (that trigger starting up/stopping a number of very expensive instances based on business hours) I have to manually update the schedule at each DST shift. AWS, do. fucking. better. I know you have the resources for it.
cholindo 3y ago
> 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 you want to be future proof (and past proof)
- midasuni 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - cholindo 3y ago
    good to know, thanks
- kodra 3y ago
  Political friendliness (n.)
- Denvercoder9 3y ago
  If you want to be future proof, you need to store locations, not timezone identifiers. The timezone database does not claim that its currently defined timezones are controlled by a single entity (i.e. one timezone can span multiple governments with timekeeping authority), nor could it possibly guarantee that in the face of changing borders and laws.
beachy 3y ago
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.
- tshaddox 3y ago
  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!
smokel 3y ago
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.
- paulddraper 3y ago
  Save the planet, remove daylight saving
- GuB-42 3y ago
  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.
- sesm 3y ago
  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.
jmuguy 3y ago
Biggest thing we did with our hospitality related app (so check-in and check-out biggest time related fields): store time and date separately. Which I know isn’t possible in a lot of applications but whenever we only needed the date - we didn’t have to worry about timezones at all. Also working with dates, times and timezones inspired me to get an ISO8601 vanity plate for my car.
- Rafsark 3y ago
  Indeed, this cannot be a solution for most of the business out there, as date and time are tied together to ingest a certain event. But this could be an easy fix for some businesses
sharts 3y ago
Seems like something people are always re-inventing solutions for when these problems have already been solved by so many others.
ucarion 3y ago
> 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/c3e966c59b02b1f47f0b7b0e4aa6a86563c07062/europe#L508 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.
- pests 3y ago
  There is a lot of interesting history in that file.
- Rafsark 3y ago
  > GMT+12, which only covers two uninhabited American islands New Zealand users are now mad at you :D
x-complexity 3y ago
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.
takinola 3y ago
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

53 points by dom_fr 3y ago

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 converted that date into midnight UTC on that date, causing many western European customers to be billed at 23:00 or earlier on the previous day from their perspective. Furthermore, from the operations side we were often dealing things that happened "on a date". I was pushing for at least our internal customer service systems to present two timestamps to agents: the date and time at which the thing occurred in the place that event occurred and also the date and time at which the thing occurred in the customer's location. For example, something being changed about a customer's account at 23:55 in London on a Monday actually happened at 00:55 on Tuesday for the customer in France. However, the timezone information was either not stored or not presented, interfaces were not consistent, and the result was pot luck whether the customer or a member of the customer service team would see Monday or Tuesday. Timezones are hard. Presenting that information in a contextually appropriate way to your own employees and customers can be just as hard. I like that the authors of the article have reached similar conclusions, especially around "dates have timezones". I think datetime capture and presentation is a fantastic UX topic.

squeaky-clean 3y ago
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 the sale-time occurs in GMT, 24 hours pass, and the sale ends in GMT. But people in American Somoa (Pacific/Midway) will still have the sale active for 11 hours. (Technically someone using satellite internet in the open ocean east of Samoa has 12 hours, but the UTC+12 timezone is completely uninhabited). Such a sale is kind of a farfetched example, but I've encountered this issue when trying to do analytics reports looking at user data that happens on specific global holidays.
- throw-ru-938 3y ago
  And when you interact with people 8 time zones away, concepts like "today" or "tomorrow" break down completely. It's a very uncanny feeling.
  - midasuni 3y ago
    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.
    - squeaky-clean 3y ago
      One member of my D&D group moved to Denmark, one moved to Tokyo. The rest of us are on the US east coast. We have the hang of it now, but for our first few online sessions there was always someone who missed it because they showed up a full day late or early. It's also funny how some of the group is having coffee and breakfast while other members are getting drunk and having midnight snacks.
    - bradknowles 3y ago
      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.
- hrrsn 3y ago
  > the UTC+12 timezone is completely uninhabited New Zealand would like a word.
  - fjfuvucucuc 3y ago
    [dead]
Denvercoder9 3y ago
The thing with dates depends on the context though. A birthday for example isn't associated with a timezone.
- Rafsark 3y ago
  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
coldcode 3y ago
When I worked at an online travel agency building our iOS app, dates were a giant pain in the ass. What is today? What is tomorrow? I covered it at https://thecodist.com/what_time_is_tomorrow_tales_from_the_time_zone/ https://thecodist.com/what_time_is_tomorrow_tales_from_the_t...
Rafsark 3y ago
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.

treve 3y ago

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 change DST quite late so you'll only know with certainty what UTC time corresponds with what local time a few weeks in advance.

Terr_ 3y ago
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 clocks at 1:00PM, wait for one sunset and one sunrise, then set their clocks to 12:00PM, and then advance it by one "minute" every time a rooster crows until it reaches 12:10pm at which point they skip straight to 3:00pm. When is your schedule your 2PM wall-clock meeting? Probably around the tenth rooster-crow. If you had reason to distrust the clock-culture of Bizarro São Paulo, you shoulda made it a different timezone. :P
- esafak 3y ago
  Can off-the-shelf libraries translate from any Bizarro time to UTC?
  - marcosdumay 3y ago
    Not in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.
    - esafak 3y ago
      So what do you do, record both the local time and UTC?

msla 3y ago

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://en.wikipedia.org/wiki/Tz_database https://www.iana.org/time-zones 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.

squeaky-clean 3y ago
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.
Rafsark 3y ago
Timezones are not hard to build. It's indeed the interpretation of your app and the display to your end users that are hard to manage. Think of your birthday: it's not hard for you to set a datetime at your current location to define when your birthday starts. But the birthday wished from your friends might changed based on the interpretation they have and where they are located

codetrotter 3y ago

I recently joined a small online forum from my country. They had some people write the whole thing from scratch more or less. I happen to be traveling currently. When I log into the forum from my location, which is one hour away time zone wise from the country the forum is from, and I make a post, I then see the timestamp for my own post presented as “in 59 minutes”. I reported the bug, but they didn’t fix it yet. I still find it hilarious. I happen to know that the owner of the forum is planning to go abroad sometime in January. If he does he will surely see this weirdness himself firsthand when he posts to his forum. Maybe then, once he gets to see it himself, a fix will be prioritised :p

Rafsark 3y ago
What would you expect as a fix? How do they know about the timezone you are currently on? Not an easy fix in my opinion as they have to be aware of your timezone (or ask for it) anytime you post
- codetrotter 3y ago
  They are rendering the timestamp with JS. JS has the ability to see system time zone offset. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... It’s not difficult to send the time zone in UTC, and convert it client side to local time zone. And since they do “x minutes ago” kind of things they are certainly using a library. They are probably passing in “naive” timestamps without TZ info into a library that is perfectly able to handle it correctly for them, had they just read the docs for the library they used and taken a moment to make sure that they include TZ info. And if everything was done server side it would likewise be similarly easy to get it right because then my own time zone does not matter.

vidanay 3y ago

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

midasuni 3y ago
The relativity and frames of reference are trivial compared to the whims of international politics
- vidanay 3y ago
  God doesn't play dice, but random governing bodies sure do.

iso8601ca 3y ago

[dead]

mschuster91 3y ago

Now if AWS would learn that lesson as well... for example, AWS Backup Plans or CloudWatch Events always run in UTC, and there's nothing I hate more than doing timezone math - and on top of that, at least for CloudWatch Events (that trigger starting up/stopping a number of very expensive instances based on business hours) I have to manually update the schedule at each DST shift. AWS, do. fucking. better. I know you have the resources for it.

cholindo 3y ago

> 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 you want to be future proof (and past proof)

midasuni 3y ago
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.
- deleted 3y ago
  [deleted]
- cholindo 3y ago
  good to know, thanks
kodra 3y ago
Political friendliness (n.)
Denvercoder9 3y ago
If you want to be future proof, you need to store locations, not timezone identifiers. The timezone database does not claim that its currently defined timezones are controlled by a single entity (i.e. one timezone can span multiple governments with timekeeping authority), nor could it possibly guarantee that in the face of changing borders and laws.

beachy 3y ago

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.

tshaddox 3y ago
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!

smokel 3y ago

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.

paulddraper 3y ago
Save the planet, remove daylight saving
GuB-42 3y ago
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.
sesm 3y ago
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.

jmuguy 3y ago

Biggest thing we did with our hospitality related app (so check-in and check-out biggest time related fields): store time and date separately. Which I know isn’t possible in a lot of applications but whenever we only needed the date - we didn’t have to worry about timezones at all. Also working with dates, times and timezones inspired me to get an ISO8601 vanity plate for my car.

Rafsark 3y ago
Indeed, this cannot be a solution for most of the business out there, as date and time are tied together to ingest a certain event. But this could be an easy fix for some businesses

sharts 3y ago

Seems like something people are always re-inventing solutions for when these problems have already been solved by so many others.

ucarion 3y ago

> 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/c3e966c59b02b1f47f0b7b0e4aa6a86563c07062/europe#L508 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.

pests 3y ago
There is a lot of interesting history in that file.
Rafsark 3y ago
> GMT+12, which only covers two uninhabited American islands New Zealand users are now mad at you :D

x-complexity 3y ago

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.

takinola 3y ago

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