Log in

No account? Create an account
DST Panic - Ulrich Drepper — LiveJournal [entries|archive|friends|userinfo]
Ulrich Drepper

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

DST Panic [Feb. 22nd, 2007|01:27 pm]
Ulrich Drepper
[Tags|, ]

With the DST rule changes for the US going into effect real soon (2007-3-11) people are panicking.

  1. there are those who run completely obsolete OSes. People contact us for support of RHL9 or even RHL7.2 (that's the predecessor of Fedora, for those who don't know. Guess what, even FC4 is not supported anymore, leave alone anything earlier. The DST change is just one of many good reasons to update. Security is the other big one.
  2. many applications are broken and they use private timezone data. In their quest to achieve perfect portability the people writing the Java runtime added the data into their sources. And unfortunately the same has been done for libgcj. Only somebody without the slightest clue about the nature of DST rules would do something like this. Would Sun/BEA/IBM/... be willing to update their JVMs 20 times a year for all DST changes (if they would have that broad support in the first place)? Of course not. Only people in countries with stable rules would not think about it. There probably hasn't been a day in the life of the JVMs when the data was really accurate. and complete.

Time zone changes are nothing special. I guess on average we see about 20 each year, maybe more. Do you see people panicking 20 times a year? No, only if the US is involved. Yes, you can argue that more computers are affected but aren't the computers which are in countries affected by those changes as important to the people living there? There are also banks, utilities, etc which need to keep the correct time.

Having lived here in the US now for quite a few years I think the root of the problem is the same that keeps the US from making progress on other fronts: fear of change and trying to prevent change through denial. Another example? Take the measurement system. When knowing the metric and the imperial system equally well, who would argue the latter is better? And it's not that people don't know the metric system at all. There are large numbers of people who serve/d in the military and all these people had to use it in their job. Every food container also shows grams. But I'm getting off-topic.

Fact is, people delay things. Delaying to update their OSes and even delaying to think about the problem. It might go away on its own and then no time has been wasted. But guess what: the DST change is coming.

So, people, get your act together. Update your OSes. If you really for some obscure reason cannot do this, update the timezone data (in /usr /share/zoneinfo). The data we have today is fully compatible, even the extended file format. Since there is no glibc update coming you could just overwrite the files without fear of reverting the changes inadvertently later. Update applications with their own timezone data. There are lots of (especially big) programs which come with their own data. The timezone data is free to copy by everybody so companies take advantage of this. Now you know why I always advised against this. More likely than not, updates for old versions of these programs are not available anymore. Make sure you let the companies who produce this kind of shitty products know what you think of them, duplicating timezone data is always bad. As for JVM: have fun! Old versions will get no updates and new version often don't run on old OS versions. At least libgcj should now be fixed for good due to the work of one of my collegues.

Once the timezone data is updated some more steps might be needed. Many programs will just work. glibc detects updates to the /etc/localtime file and reloads the data. Lots of people complained about this in the past and present since it means time operations cause my filesystem operations, but it is critical in some situations. If a process only uses the time functions which do not implicitly call tzset() they must be restarted. The same is true for processes which have the TZ environment variable set. In general you cannot know whether a process falls into any of the later categories. The safest thing to do is to reboot the machine.


[User Picture]From: fanf
2007-02-22 11:16 pm (UTC)
If you think Unixy people are panicking, then I recommend having a look at the state of the Windows world. The examples you give of how not to do it are NOTHING compared to the train wreck that is Microsoft Exchange. They embed fixed timezone data within all events, which means that all of the data you have stored in an Exchange system must be scanned and rewritten so that its TZ data can be fixed up. I can see why they might have made this mistake for calendar events, but the problem extends to stored email too. Incredible!
(Reply) (Thread)
[User Picture]From: abbra
2007-02-23 07:10 am (UTC)
If my application is running under 'stable' timezone (as MSK or GMT+3) and it is not communicating/parsing dates from outside the computer (i.e., it is not a MUI or web browser or something comparable), should it be restarted?
(Reply) (Thread)
From: udrepper
2007-02-23 09:37 pm (UTC)

It Depends As Usual

If my application is running under 'stable' timezone (as MSK or GMT+3) and it is not communicating/parsing dates from outside the computer (i.e., it is not a MUI or web browser or something comparable), should it be restarted?

The libc code always only uses the timezone indicated by /etc/localtime and TZ. These values are process-global and should not be touched by the process. Specifically they should not be used to print time values for other time zones. I'm fortunately not aware of code which does that.

So, processes which limit their timezone use to the way the libc uses it and which don't mess with /etc/localtime and TZ and which are not affected by the DST change since they are not using a US, Canada, Bermuda, ... timezone need not be restarted.

Having said that, there might be programs out there which violate the rules. And there might be programs out there which read the timezone data directly (the format is vary stable). The new libgcj after Jakub's patch falls into this category. In this case all bets are off and a restart is likely necessary.

But as I said before: timezone changes happen all the time. For everybody outside the directly affected region this is not much different from any other day an RPM with new timezone data arrives.

(Reply) (Parent) (Thread)
[User Picture]From: abbra
2007-02-24 06:58 am (UTC)

Re: It Depends As Usual

Thanks. For regular users (desktop case) I think we could worry about browser, mail client, and instant messaging mostly as they could get dates in responses from server/other client in an unexpected timezone which observed DST change. Fortunately, most of them don't work with time w/o libc except for mentioned Java-based cases.

It looks like timezone RPM need to issue warning to the user that all such applications are better to recycle after update. One thing here is that RPM doesn't allow for interactivity during install but may be something like DBUS and gnome sidebar messages could be in help here for clever post-install scripting?
(Reply) (Parent) (Thread)