December 2007 Cumulative Time Zone Update is Now Available [Josh Free]

In case you have not heard, the December 2007 cumulative time zone update for Microsoft Windows operating systems is now available.  The update can be downloaded right now from; the software update will also be available via Windows Update on an upcoming date.  This update includes everything previously released in the August 2007 cumulative time zone update plus additional time zone changes that were singed in to law after the August 2007 update was created.  This includes updates to existing standard time zones such as Arabic, Australia (Central, Eastern, and Tasmania), Egypt, Israel, and South America (E. South America, Central Brazilian).

The most notable change is the inclusion of a new time zone for the capital of the Bolivarian Republic of Venezuela, Caracas:


Display Name

Standard Name

Daylight Name

DST start

DST end

Venezuela Standard Time

(GMT-04:30) Caracas

Venezuela Standard Time

Venezuela Daylight Time

12/31/2007 at 24:00

Not applicable

The TimeZoneInfo class can use the new time zone by referencing its identification string “Venezuela Standard Time”

To date Venezuela has typically observed South America Western Standard Time but is in the process of migrating to the new time zone — adjusting clocks backwards 30 minutes, from UTC -4:00 to UTC -4:30.  According to the latest news reports on the official Venezuelan government news site (see translated page) the start date may or may not be changed again between now and the end of calendar year 2007.

Additional Information

For the latest information on time zone changes please refer to the Microsoft Daylight Saving Time & Time Zone FAQs Blog, Hot Topics for Daylight Saving Time changes in 2007, and

Update: Fixed typo in the table.

Comments (5)

  1. Miral says:

    I’m assuming the reversal of Standard and Daylight time is a typo?

  2. Chronos says:

    As noted more than a year ago, TimeZoneInfo is fundamentally broken. This represents the first real instance, with more in the near future.

    As a developer, I can not assume that all clients will have the latest patches installed, such as this one. Hence, I can *not* depend on the data returned from the type. Rather, I will *always* need to import fresh data (probably from tz). Thus, the type is always broken by default. I can do the work, but you do not allow us to override the type and there is no ITimeZoneInfo interface, so again my hands are tied.

    Don’t even get me started on the problems of DateTime… which could be fixed if you would give us an IDateTime interface!

  3. Josh Free says:

    Yes, it is definitely true that you can never depend on every user’s system having the latest patches installed from Windows Update.  It doesn’t make too much sense for an application to redistribute static tz data, which will become outdated as countries change their tz rules after the application has shipped.  For standalone client applications the guidance is to rely on the tz data on the local computer, since using this data allows the application to behave consistently with all other applications on the machine.

    For client-server/multi-machine scenarios where you need to have all of the machines using the exact same tz data, we tried to make this scenario easy by letting applications quickly send the server’s tz data to the clients over the wire.  On the server, applications can serialize a TimeZoneInfo instance to a String by using the ‘ToSerializedString()’ instance method.  On the client, applications can then de-serialize the string back into a TimeZoneInfo object by calling the static method ‘TimeZoneInfo.FromSerializedString(String source)’.

    Finally, if you do not have a client/server scenario as mentioned above, but you do want to ship embedded timezoneinfo instances in a client application instead of using the data from the client’s OS, please see the MSDN article:  "How to: Save Time Zones to an Embedded Resource"

  4. Dean Harding says:

    Re: ToSerializedString() and FromSerializedString()

    Is the any reason why you didn’t just make the types serializable? That would seem like a no-brainer to me.

  5. Chronos says:

    "It doesn’t make too much sense for an application to redistribute static tz data […]"

    Who said anything about being static? The tz data can be downloaded* and imported as necessary. I generally cache the results for a week, but allow options to modify this as needed.

    * tz database

    If anything is static, it could just as well be the clients timezone info since they may have never installed the Windows updates.

    I can and do work around these limitations with my own custom type. However, my type does not fit into the new framework because you do not allow me to extend your type nor are there any interfaces to implement.

Skip to main content