Citation needed for comparisons within a single time zone.

Nothing is natural about how we wake and go to sleep these days, I'm not sure why that would matter.

Today for example, where I live in BC (which is essentially along the border) sunrise was at 6:51am (with it starting to get light even before that) and sunset will be 5:59pm (with it still being light a bit later than that of course)

If we spring ahead to the new system, it would mean sunrise would have been at 7:51am, with sunset at 6:59pm.

When I got up this morning at quarter to 7am to my alarm beeping, even though sunrise was just about to occur, the first thing I did was turn on my bedroom light so that I could see. My blinds were closed, so I could not tell if it was light or dark outside.

When I get home, I will turn on my house and room lights for multiple hours before I go to bed tonight.

Dec 21st would have been sunrise from essentially 9am to 5pm, instead of 8am to 4pm. Either way I'm waking up in the dark, and going to bed in the dark.

In the deepest parts of summer, it is light before I wake up and is just barely reaching darkness before I go to bed most nights. Under standard time it would actually be dark before I go to bed... maybe that's the benefit?

Less natural for the body? I don't understand... The amount of daylight available remains the same.

it's all pretty pointless unless the whole continent agrees to change.

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.

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.

I’m not a morning person. But I like the roads to be less frozen when I go to work. I like it to be brighter so there are less accidents. And I like kids being able to walk to school with some sunlight in winter.