4 ms·
After the DST transition last fall I did some analysis using our dataset at Cronitor: After removing jobs that ran every hour, just a little under 20% of jobs r
by encoderer 8y ago
After the DST transition last fall I did some analysis using our dataset at Cronitor: After removing jobs that ran every hour, just a little under 20% of jobs ran twice. Most versions of Crontab handle DST changes correctly but there are a lot of ways to scheduled jobs and this will be a win for a simpler spec creating more reliable systems that are easier to reason about.
- tzs 8y agoIn 1984 I had a coworker who booted his Unix workstation and found that the date was Jan 1, 1970. The battery that powered the clock that kept the time when the system was off had died. He set the time to the correct time. Cron then tried to start every cron job that would have run between Jan 1, 1970 and the current date in 1984. That's about 120k instances for every hourly job, 5k instances for every daily job, 700 instances for every weekly job, and a mere 170 instances for every monthly job. That completely locked up the workstation. It was hilarious.
- zaarn 8y agoMy solution for that: Set all servers to UTC and use smearing NTP servers. UTC doesn't have summertime, so the clock doesn't suddenly change and the smearing NTP will prevent leap seconds from doing the same. Timezones should be accounted for in the UI, not the backend.