Comment 6 for bug 1437805

tzdata is merely data. It doesn't *do* anything, and certainly doesn't magically change the time. It contains information on how to convert system time (UTC offset from the UNIX epoch) into the correct localtime, based on your $TZ selection or /etc/localtime, but it's up to applications displaying the time to actually call into the correct libc functions to give you an appropriate time.

Usually where this goes wrong is that people will ask glibc for a correct time once on startup, and then start an internal counter and increment that, never going back to check on reality.

Common fixes for this that don't cause intense load tend to be things like only checking localtime when each minute ticks over, or only checking when an application is actually displayed in the foreground. Obviously, the latter would be completely wrong for an alarm clock, and the former would cause unwanted wakeups on a phone, but one could be clever and ask about future stamps in advance, if you're setting up wakeup events.

ie: Ask the system to mktime your next alarm time (or next N alarm times) and store the correct wakeup events as neutral timestamps, so that even if DST happens while you're asleep, the next alarm happens correctly anyway.