[ig1]

No. Every piece of software that deals with time in any kind of sophistication needs to have logic to handle it.

I used to work on a share price alerting system where you could say "if the price of stock X goes up by 10% during these hours than alert me", that creates a nightmare when it comes to DST changes. Do you use the timezone of the person who setup that alert (what if they're now in a different timezone do you change ?) or do you use the DST rules of the country the share trades in.

Imagine you have a calendaring app and someone from another country sends you a meeting request for the future that's past a DST change in one of your countries, but not past it in the other. It's possible for the time to be ambiguous unless you specify DST handling rules. What happens if a country changes DST rules (this happens far more often than you think) how do you adjust previously set appointments ?

Imagine your Google Analytics, what timezone do you save analytics data in and do you adjust for DST (the answer is PST by default, and if you change it, historical data won't be adjusted so you end up with a mishmash of time data).

In any scenario where you have to handle timezones it's complicated enough as it is, DST handling makes it a nightmare.

[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.