11–20 of 65 posts
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…
AWS, do. fucking. better. I know you have the resources for it.
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…
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…
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…
> 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…
You can’t always be future proof.
Earlier quoted context omitted.
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…
Can off-the-shelf libraries translate from any Bizarro time to UTC?
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…
And when you interact with people 8 time zones away, concepts like "today" or "tomorrow" break down completely . It's a very uncanny feeling.
It was quite surreal, although time wise I think the LA person was up early on Tuesday and I was up late.
Timezones are easy. All you need is a complete understanding of Special Relativity and inertial frames of reference. Bada bing, bada boom.
> 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.
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.
It's also funny how some of the group is having coffee and breakfast while other members are getting drunk and having midnight snacks.