[reedf1]

It's pretty astounding to me the number of pro-DST advocates in this forum. If you had hundreds of daily jobs on your platform and you happen to have some regular requirement to change them in unison, if a junior engineer said "let's just change the system clock to adjust for when we want the jobs to run", you would say no, because while it might be easy compared to changing the config for each of the jobs, the risk of ongoing errors, side effects, introduction of jobs that need to fixed in absolute time that you have to make the inverse change... It's a system nightmare.

[apexalpha]

I live in the Netherlands.

In the summer the suns up at 5 am. But at 5am I am asleep. I could get up earlier but that's pointless since school and work doesn't start until 8.30.

So in stead of having an hour of sunlight before school and work we all change our clocks to have an hour of extra sunlight in the evening in stead, which fits our cultural preference for social activities.

We could also, as you say, change every single sign, post and display of opening hours for every school, business and organisation at the same time to achieve the same effect.

But in the real world changing the clock is simpler.

[literalAardvark]

So change it... just permanently. GMT+2 will always be there for you.

[duckmysick]

Then you will have the opposite problem in winter. Sunrises would be 9am-10am for about three months.

[stefandesu]

> Sunrises would be 9am-10am for about three months.

At least you'd get some sun after work. Here in Norway, the only way to get sunlight during a workday in winter is to go out during lunch break. While I do acknowledge that getting sunlight in the morning is more important than in the afternoon, I feel like subjectively I'd have more use for a little bit more sunlight after work than before work.

[tristanj]

That means waking up for work 2-3 hours before sunrise, and starting work before dawn.

I'd very gladly have a more natural sleep schedule than some sun in the afternoon.

[joquarky]

Maybe we should go back to sundials.

[apexalpha]

Then sun rises at 9am in the winter, which is too late.

Our daylight moves with the seaons. So therefor our clock does as well.

I understand some countries that are much closer to the equator might question it now but for us it just makes sense.

[f33d5173]

It's a fairly trivial change. We already have timezones, which exist to deal with the fact that the sun comes up at different times in different parts of the world. We already have to design everything around the assumption that timezones can change, since people sometimes move to different parts of the world. All we do is cause, for an entire timezone, that it becomes a different timezone at one point in the year, and switches back later. This ensures that the sun continues to come up at a consistent time. The main issue it causes is to make the lives of programmers slightly more difficult, which I am sure they can cope with...

[artisinal]

That is why you run your jobs on GMT/UTC and not display time.

[reedf1]

I guess that is what I'm trying to show in the above example. You could technically shift your UTC jobs by running your own NTP server and desyncing it from UTC by the offset you want. It would work, but it would be nightmare fuel. And possibly this is an even better example of what DST is doing.

[kuboble]

Well, it's not that obvious.

Some jobs should run every day at 8 am (e.g. torn on the temporary speed limit on front of the school), vs tasks that should actually run every 24h (e.g. feed the bacteria in exact time intervals)

[edoceo]

The jobs need to run at midnight, local time. Which shifts from UTC. How to handle?

[defrost]

Why does it need to run at that time?

* If it's being run to scrap data from a source that's available at some time, adjust the job if the source changes its time.

* If it's being run "when its dark and no one is around" then it'll run at some part of the dark bit regardless of DST changes.

[Retric]

Sometimes you minimize downtime by running something while some other system you don’t control is down.

[edoceo]

Billing and regulatory compliance

[defrost]

In that specific case, handle the job time by making it compliant.

The reason I posed a leading rhetorical question was that not all cron jobs are equal and how each is handled depends on the nature of each.

[ssl-3]

Use UTC, and stop faffing about with changing localtime twice every year so the offset is a constant?

[anal_reactor]

Imagine having a solution that already works with changing system clock but then some very big very important very senior very developer shows up and launches a multi-year project to redesign this, potentially opening pandora box of endless bugs. PhD in Job Security, typical shit I see in corporate.

[reedf1]

To be clear if I showed up to a company running their own company NTP server that they desync twice a year to make timings work - I would absolutely try to migrate them away from that. Now if they are doing that there is probably bigger fish to fry... but it would be on the list.

[smitty1e]

Everybody's "Blatantly Obvious To A Casual Observer" (BOTACO) solution is somebody else's "Scam Amounting to Large Amounts of Dollars" (SALAD).

[fmajid]

Thee golfing industry is one of the big proponents of keeping DST and lovbbies hard for it.