[weinzierl]

Unix-like systems like Linux and OSX handle that very well. The hardware real time clock ticks in UTC, file timestamps and the like are stored in UTC. The OS knows everything about time zones and DST and therefore can display the time the way you expect it.

[jrockway]

The problem goes the other way. If a user says, "run this job at 1:10AM", does the job run twice when 2am becomes 1am at the DST switch? If everyone input times in UTC, it would be fine, but users want to input and output.

I am lucky to be able to avoid this problem, because while I do have users that want to read and write times in their local time zone, they are asleep at 1am and automated stuff tends to run at midnight. Sometimes the dice roll in your favor :)

[ig1]

Current time is only a small part of time handling, practically every crontab implementation handles DST differently due to the ambiguity in the posix standard which just states that time stamps have to be in local time taking no account that this can mean a scheduled task can incorrectly get run twice or never.