Better idea... why doesnt the whole world just switch to UTC? Its already there, and already widely supported. This switch has already happened in the scientific and military communities; its going to have to happen in the civil sphere one day. Why not now?
As you note, there is no centralized timezone database maintained by a government agency. Instead, the TimeZone DB (http://www.twinsun.com/tz/tz-link.htm) is updated by hundreds of volunteers around the world.

Governments fail in two ways: 1) They fail to report timezone changes in any standard way or place. Thus, many timezone changes are discovered after the fact. 2) Governments fail to recognize that it does take time for timezone changes to propagate to all affected parties.

The same problems occur for currency changes, but they occur much less frequently.
As far as I can see, the Argentine government announced on 21 December 2007 that the change would take effect from 30 December 2007! That's 9 actual days, but because of weekends and Christmas breaks, only three working days which many people will already have booked as holiday. There simply hasn't been time to develop the rules. It wasn't rolled into the earlier updates because the developers didn't know about it!

As for your server idea, it doesn't help systems that aren't connected to the internet or that are firewalled. Typically if a network gets its time from NTP, it's only one or two servers (e.g. the domain controllers) that do, and everything else syncs to those. This stops the systems getting out of step with each other.

Traditionally Windows simply had a single entry per time zone which said whether DST was in use and information to compute the transition dates (e.g. last Sunday in March, at 2am local). These values would be applied to historical data (e.g. to convert file timestamps - NTFS stores in GMT). These updates - or possibly XP SP2 - add the ability to have historical DST data as well.
NTP doesn't deal with daylight saving because it knows nothing of local time--all the times it deals with are in UTC.

Unlike Dimdows, Unix and Linux systems are quite able to stay up to date with timezone changes. That's because they invariably get their timezone data from the Olson database <http://www.twinsun.com/tz/tz-link.htm>, and this is data, not code, so updating it doesn't actually require any code patches.
I don't know if you noticed, but over at WorldTimeServer.com the current timezone for Argentina is listed as DST -0400 UTC.
Something tells me that when the guys who make money out of timezones get it wrong, we'll have to wait for a central timezone server.
I'm still waiting for the updated tzdata package.
sysadmins in the US have been going though this pain over the last year.

it's easy to setup a new timezone file to match your location, what isn't easy is to figure out all the places where times are stored and which ones need to be changed. This is what 'breaks' outlook and exchange. they store the local time in the database for the scheduling and when you look at it you have no way of telling if the time was stored before the timezone file was changed or after. if it was stored before then it needs to be changed, if it's stored after then it doesn't

to make matters even worse, the before and after mentioned above aren't when the exchange server had it's timezone file changed, but when the client that outlook is running on had it timezone file changed.

the right answer is to store the times in GMT and modify them as they are read and queried, but that's not how the software was written
Irresponsible of Argentinian gov to give 4 days notice of a change of time zone policy
I'm a little surprised that this article hasn't pointed out that it's totally irresponsible of the Argentinian government to give their country (and the rest of the world!) 4 days notice before changing a particular time zone policy.

With Microsoft's monthly patching policy (second Tuesday of the month) and the particular time of the year this was done (inbetween Christmas and New Year when many companies will be on skeleton or no staff in work), the lack of notice is even more scandalous.

BTW, Linux users can test their distro by setting TZ=ART3 - Fedora 8 had an update to their timezone files on 4th December 2007 and even that is still showing GMT-3. I suspect most other distros are in the same boat.

A big slap on the wrists for the Argentinian government (yes, it may have been in draft for weeks, but it's when the Act is actually enabled that matters) for their poor administration on this subject.
Fernando, I'm the first on queue to start bashing on MS and their kingdom but give me a break. All of a sudden this bitch we have for a president decides 5 FREAKING DAYS before the actual change that we'll be implementing DST. I mean, this kinda things have to be done within real life timelines, not just a week before. In this particular case, the government is 100% guilty for this chaos, not MS.
I created an idiot-proof guide to fix this mess in a fully automated way (based on an official MS blog). If you care to read it, head to http://www.animeforos.com.ar/general/3489-importante-cambio-de-zona-horaria-en-windows.html
You suggest that an OS could determine a user's country or that an "enhanced" NTP could take a user's country as an argument to allow determining the correct local time.

You seem to be forgetting that many countries have more than one time zone. The US has four, Russia has something like 11 I believe. Additionally, in the US, Hawaii and Arizona don't observe daylight savings time, as well as some US territories.

What's more, in the recent past some counties in the state of Indiana had differing DST policies, and these counties are probably smaller than the total area of the city of Buenos Aries. Even today, in Arizona the Navajo reservations do observe DST while the rest of Arizona doesn't. I'm sure the US isn't the only country in the world with such a complicated time zone or DST situation.

I think you believe that geolocation works a bit better than it really does if you think it can narrow done one's location to the required degree of accuracy. My own IP address maps to a location over 10 miles away, if that happened to be across a time zone boundary line I'd get the wrong time from everything, instead of today's situation where its just the software or devices that are stupid.

Broken software can be fixed. Microsoft may eventually fix their software to solve your problem. Broken design can't be so easily fixed. If we relied on geolocation or an enhanced NTP, there would be a lot of people permanently using the incorrect time!
How about we get rid of DST entirely, since we now know that it doesn't actually save energy?

Then we actually would know what time it is, simply going by UTC and the timezone.
Yea, most of the stuff Windows comes with is not supposed to work or be useful in any way. How will all those companies that sell software for Windows make a bug buck otherwise? Changing the time zone would break Outlook? HAHAHAHA, lool, what can I say, pathetic Vole.
Wait a second, the Argentine government decides on 26th December that the timezone for an entire nation is changing FOUR DAYS LATER and you're outraged at the OS vendors? Get a grip!

NTP is quite rightly timezone-neutral, all of its transactions are UTC. Linux and UNIX systems are they same - they all store the time internally as UTC, timestamps on files are UTC, everything is UTC until it's displayed to the user.

Further, having your machine constantly refer to an internet source for timezone information is rediculous. Not every machine is, can, or should be connected to the internet. The timezone information must be part of the operating system.
Fedora, Mozilla et. al depend on volunteers to build the software in the first place.

So why waste time with almanachs which may by inaccurate no matter how fresh they are, as nobody knows which madman-in-chief changes "times" just for the sake of it, at any given moment.

People living in any given country, or territory always know and know the first.

So if a volunteer system is set up, and somebody at RedHat or Canonical charged with monitoring the submissions, then each time a change in DST is submitted by a volunteer, this person gets notified, verifies the facts and makes official changes in the DST database.

It doesn't happen THAT often that these Open-sorcerers would have to actually pay such person a burdensome full-time salary.
Perhaps your government should be a bit less shortsighted when passing such laws? Allowing less than a week for patching of affected computer systems is a bit ridiculous.

We went through a similar DST change early this year in the US. However, the law had been passed several months prior to the actual change taking effect, which allowed much more time for patches to be created and for businesses to apply these patches. Not to say that there weren't still issues, but it was a fairly smooth transition overall.
Better idea... why doesnt the whole world just switch to UTC? Its already there, and already widely supported. This switch has already happened in the scientific and military communities; its going to have to happen in the civil sphere one day. Why not now?
As you note, there is no centralized timezone database maintained by a government agency. Instead, the TimeZone DB (http://www.twinsun.com/tz/tz-link.htm) is updated by hundreds of volunteers around the world.

Governments fail in two ways: 1) They fail to report timezone changes in any standard way or place. Thus, many timezone changes are discovered after the fact. 2) Governments fail to recognize that it does take time for timezone changes to propagate to all affected parties.

The same problems occur for currency changes, but they occur much less frequently.
As far as I can see, the Argentine government announced on 21 December 2007 that the change would take effect from 30 December 2007! That's 9 actual days, but because of weekends and Christmas breaks, only three working days which many people will already have booked as holiday. There simply hasn't been time to develop the rules. It wasn't rolled into the earlier updates because the developers didn't know about it!

As for your server idea, it doesn't help systems that aren't connected to the internet or that are firewalled. Typically if a network gets its time from NTP, it's only one or two servers (e.g. the domain controllers) that do, and everything else syncs to those. This stops the systems getting out of step with each other.

Traditionally Windows simply had a single entry per time zone which said whether DST was in use and information to compute the transition dates (e.g. last Sunday in March, at 2am local). These values would be applied to historical data (e.g. to convert file timestamps - NTFS stores in GMT). These updates - or possibly XP SP2 - add the ability to have historical DST data as well.
NTP doesn't deal with daylight saving because it knows nothing of local time--all the times it deals with are in UTC.

Unlike Dimdows, Unix and Linux systems are quite able to stay up to date with timezone changes. That's because they invariably get their timezone data from the Olson database <http://www.twinsun.com/tz/tz-link.htm>, and this is data, not code, so updating it doesn't actually require any code patches.
I don't know if you noticed, but over at WorldTimeServer.com the current timezone for Argentina is listed as DST -0400 UTC.
Something tells me that when the guys who make money out of timezones get it wrong, we'll have to wait for a central timezone server.
I'm still waiting for the updated tzdata package.
sysadmins in the US have been going though this pain over the last year.

it's easy to setup a new timezone file to match your location, what isn't easy is to figure out all the places where times are stored and which ones need to be changed. This is what 'breaks' outlook and exchange. they store the local time in the database for the scheduling and when you look at it you have no way of telling if the time was stored before the timezone file was changed or after. if it was stored before then it needs to be changed, if it's stored after then it doesn't

to make matters even worse, the before and after mentioned above aren't when the exchange server had it's timezone file changed, but when the client that outlook is running on had it timezone file changed.

the right answer is to store the times in GMT and modify them as they are read and queried, but that's not how the software was written
I'm a little surprised that this article hasn't pointed out that it's totally irresponsible of the Argentinian government to give their country (and the rest of the world!) 4 days notice before changing a particular time zone policy.

With Microsoft's monthly patching policy (second Tuesday of the month) and the particular time of the year this was done (inbetween Christmas and New Year when many companies will be on skeleton or no staff in work), the lack of notice is even more scandalous.

BTW, Linux users can test their distro by setting TZ=ART3 - Fedora 8 had an update to their timezone files on 4th December 2007 and even that is still showing GMT-3. I suspect most other distros are in the same boat.

A big slap on the wrists for the Argentinian government (yes, it may have been in draft for weeks, but it's when the Act is actually enabled that matters) for their poor administration on this subject.
This website is useful for most basic purposes:

http://timeanddate.com/worldclock/full.html
Fernando, I'm the first on queue to start bashing on MS and their kingdom but give me a break. All of a sudden this bitch we have for a president decides 5 FREAKING DAYS before the actual change that we'll be implementing DST. I mean, this kinda things have to be done within real life timelines, not just a week before. In this particular case, the government is 100% guilty for this chaos, not MS.
I created an idiot-proof guide to fix this mess in a fully automated way (based on an official MS blog). If you care to read it, head to http://www.animeforos.com.ar/general/3489-importante-cambio-de-zona-horaria-en-windows.html
You suggest that an OS could determine a user's country or that an "enhanced" NTP could take a user's country as an argument to allow determining the correct local time.

You seem to be forgetting that many countries have more than one time zone. The US has four, Russia has something like 11 I believe. Additionally, in the US, Hawaii and Arizona don't observe daylight savings time, as well as some US territories.

What's more, in the recent past some counties in the state of Indiana had differing DST policies, and these counties are probably smaller than the total area of the city of Buenos Aries. Even today, in Arizona the Navajo reservations do observe DST while the rest of Arizona doesn't. I'm sure the US isn't the only country in the world with such a complicated time zone or DST situation.

I think you believe that geolocation works a bit better than it really does if you think it can narrow done one's location to the required degree of accuracy. My own IP address maps to a location over 10 miles away, if that happened to be across a time zone boundary line I'd get the wrong time from everything, instead of today's situation where its just the software or devices that are stupid.

Broken software can be fixed. Microsoft may eventually fix their software to solve your problem. Broken design can't be so easily fixed. If we relied on geolocation or an enhanced NTP, there would be a lot of people permanently using the incorrect time!
How about we get rid of DST entirely, since we now know that it doesn't actually save energy?

Then we actually would know what time it is, simply going by UTC and the timezone.
Yea, most of the stuff Windows comes with is not supposed to work or be useful in any way. How will all those companies that sell software for Windows make a bug buck otherwise? Changing the time zone would break Outlook? HAHAHAHA, lool, what can I say, pathetic Vole.
Wait a second, the Argentine government decides on 26th December that the timezone for an entire nation is changing FOUR DAYS LATER and you're outraged at the OS vendors? Get a grip!

NTP is quite rightly timezone-neutral, all of its transactions are UTC. Linux and UNIX systems are they same - they all store the time internally as UTC, timestamps on files are UTC, everything is UTC until it's displayed to the user.

Further, having your machine constantly refer to an internet source for timezone information is rediculous. Not every machine is, can, or should be connected to the internet. The timezone information must be part of the operating system.
Fedora, Mozilla et. al depend on volunteers to build the software in the first place.

So why waste time with almanachs which may by inaccurate no matter how fresh they are, as nobody knows which madman-in-chief changes "times" just for the sake of it, at any given moment.

People living in any given country, or territory always know and know the first.

So if a volunteer system is set up, and somebody at RedHat or Canonical charged with monitoring the submissions, then each time a change in DST is submitted by a volunteer, this person gets notified, verifies the facts and makes official changes in the DST database.

It doesn't happen THAT often that these Open-sorcerers would have to actually pay such person a burdensome full-time salary.
Perhaps your government should be a bit less shortsighted when passing such laws? Allowing less than a week for patching of affected computer systems is a bit ridiculous.

We went through a similar DST change early this year in the US. However, the law had been passed several months prior to the actual change taking effect, which allowed much more time for patches to be created and for businesses to apply these patches. Not to say that there weren't still issues, but it was a fairly smooth transition overall.