undefined | Better HN

0 pointse28eta2y ago0 comments

It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly.

I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik the time change happens during the hours most people are asleep, but the ruby API being used had errors for “there are zero / two times that match the time you asked for”.

I had to scratch my head for a little on why we were seeing both the zero and two errors in September / October, despite being intellectually well aware that the southern hemisphere seasons are the opposite of the northern.

0 comments

6 comments · 1 top-level

takinola2y ago· 5 in thread

But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up.

Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.

recursive2y ago

It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.

out_of_protocol2y ago

Well, when it's not time, just some numbers. The most you can do is to store as is, hoping to figure out what that means later.

Also, even if all inputs and outputs are in local time, it still makes sense to process everything in UTC. There are a lot of weird corner cases making math on datetime really complicated

1 more reply

latchkey2y ago

I worked in a system a long time ago where someone came up with the bright idea of running batch jobs in such a way that the job would complete by the time we were in the users timezone morning hours. You know, so they could get the data when they were awake.

As time went on, the jobs started taking longer and longer and eventually took longer than the whole local morning, which resulted in them being awake AND being able to complain about it. The other issue was DST... users who were used to waking up and getting their data right away... would either be delayed an hour, or be done an hour early. Sometimes, the jobs would also run 2x or not run at all.

It was an utter mess of unintended consequences.

e28etaOP2y ago

It was checking for something like “is it 9am in PST / PDT right now? What about EST / EDT?”

Or maybe, “what’s the current time in this list of time zones and then I’ll send notifications to users where it’s 9am”

Or something, I don’t specifically remember. The point is that notifications aren’t generated until they’re supposed to be sent, and we didn’t want that to vary by 1 hour with daylight savings.

And this specific use case aside, I think it’s true that there’s a class of use cases where developers do need to consider DST.

takinola2y ago

I have no doubt that this may have been some crazy complicated case (as dealing with time can be) but I can't help the armchair quarterback debugging. Could this not have been addressed by periodically running a script that generated when (in UTC) a notification should be sent and then another script to send the notifications when that time comes around ie

Script 1: send notification to User 123 at 9:00 UTC

Script 2: It is 9:00 UTC, which users are due to have notifications that have not been sent?

This way, the timezones don't ever really come into play. The axiom I follow for dealing with time is collect and display time in user's local time but store and process in UTC.

1 more reply

j / k navigate · click thread line to collapse

0 comments

6 comments · 1 top-level

takinola2y ago· 5 in thread

But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up.

recursive2y ago

It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.

out_of_protocol2y ago

Well, when it's not time, just some numbers. The most you can do is to store as is, hoping to figure out what that means later.

Also, even if all inputs and outputs are in local time, it still makes sense to process everything in UTC. There are a lot of weird corner cases making math on datetime really complicated

1 more reply

latchkey2y ago

It was an utter mess of unintended consequences.

e28etaOP2y ago

It was checking for something like “is it 9am in PST / PDT right now? What about EST / EDT?”

Or maybe, “what’s the current time in this list of time zones and then I’ll send notifications to users where it’s 9am”

And this specific use case aside, I think it’s true that there’s a class of use cases where developers do need to consider DST.

takinola2y ago

Script 1: send notification to User 123 at 9:00 UTC

Script 2: It is 9:00 UTC, which users are due to have notifications that have not been sent?

This way, the timezones don't ever really come into play. The axiom I follow for dealing with time is collect and display time in user's local time but store and process in UTC.

1 more reply

j / k navigate · click thread line to collapse