301
BC Gov News- British Columbia is moving to permanent Daylight time
(news.gov.bc.ca)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Mar 2026
301 points (100.0% liked)
Uplifting News
18340 readers
68 users here now
Welcome to /c/UpliftingNews (rules), a dedicated space where optimism and positivity converge to bring you the most heartening and inspiring stories from around the world. We strive to curate and share content that lights up your day, invigorates your spirit, and inspires you to spread positivity in your own way. This is a sanctuary for those seeking a break from the incessant negativity and rage (e.g. schadenfreude) often found in today's news cycle. From acts of everyday kindness to large-scale philanthropic efforts, from individual achievements to community triumphs, we bring you news—in text form or otherwise—that gives hope, fosters empathy, and strengthens the belief in humanity's capacity for good, from a quality outlet that does not publish bad copies of copies of copies.
Here in /c/UpliftingNews, we uphold the values of respect, empathy, and inclusivity, fostering a supportive and vibrant community. We encourage you to share your positive news, comment, engage in uplifting conversations, and find solace in the goodness that exists around us. We are more than a news-sharing platform; we are a community built on the power of positivity and the collective desire for a more hopeful world. Remember, your small acts of kindness can be someone else's big ray of hope. Be part of the positivity revolution; share, uplift, inspire!
founded 2 years ago
MODERATORS
What sorts of issues? It's been common for decades to store time in UTC, and render local time on the client side.
So as s simple example from the system I work with:
Customers can set rolling validities for alerts, e.g., Monday 8-10.
If a customer from a place which currently has DST puts in 8-10 say, CEST, in their browser (6-8 UTC) then they intuitively expect this to still be 8-10 their local time (7-9 UTC) when later winter time rolls around.
But, all data checked for alerts comes in in UTC and different users editing these validities are from different countries, timezones and summer time preferences.
Gets funky really quickly. Especially because the evaluation has to account for the DST shift essentially on a per-recipient DST-when-configured vs DST-when-evaluated basis.
(This is genuinely a simple example, it gets worse 😁)
Yeah, I've had my share of timezone madness, but usually anytime timezones are involved, the DST doesn't cause too much more extra work (except for potentially creating invalid times in the spring you have to handle).
It's been a while, but i worked on something similar long ago, and the way we did it was in the user's profile, store the TZ identifier, so for example
Europe/Berlin. We had alerts for users stored in an alerts table, and there was a column for "last sent" and "next scheduled". Everytime an alert was sent, it would check the user's profile and use the TZ info to generate the UTC time that the next email should go out and update "next scheduled" field with the UTC value. Granted the options for the schedule were fairly limited (every hour, every day, every month), but it worked pretty flawlessly from what I recall.I manage a bunch of code that has to handle that sort of thing, since no customers have complained I haven't had to check into it. Now that I've typed this I imagine I'll get an issue next week cause last person who did it wasn't so great with that stuff. Seems to work so easier to let it be till it doesn't.
Mostly installed locally but we do have some hosted customers on central servers, either they haven't noticed issues or it works. I'd put money on the former than latter though.
Not the person you responded to , but the "render local time on the client side" is the tricky part, especially when the time is in the past or future relative to current. Theres a hundred edge cases to consider and many of them very non-obvious to our feeble linear time oriented mortal minds.
Yes, I'm familiar with the Tom Scott video, but even he says at the end to store data in UTC and use a library like tzdata for rendering, don't do it yourself. I was more curious about what day to day issues were happening because of DST, since that seems like bad implementation, and not an impossible problem that would be causing half of all IT issues.