CUCM Daylight Savings Problems

Daylight savings time can be a problem, as the start & stop dates aren't necessarily the same every year due to legislative changes. For example this year Brazil changed the start date for DST, thus causing CUCM to change the time displayed on phones a week earlier than is correct.
CUCM uses the Olson timezone database, for which Cisco fairly regularly release patches to match changes to timezones around the world, so it is worth updating if you work on a multi-national deployment.
Unfortunately there's not a way to view when CUCM thinks it should be changing to DST from the GUI, but with a little bit of SQL we can get at this information to validate it.

First run show timezone list to view the available timezone names:

admin:show timezone list

   0 - Africa/Abidjan
   1 - Africa/Accra
   2 - Africa/Addis_Ababa
   3 - Africa/Algiers
   4 - Africa/Asmara

Then select * from typetimezone:

admin:run sql select * from typetimezone where name like 'America/Sao_Paulo'
enum name              description          moniker                    bias stddate             stdbias dstdate              dstbias abbreviation legacyname                             
==== ================= ==================== ========================== ==== =================== ======= ==================== ======= ============ =======================================
17   America/Sao_Paulo (GMT-03:00) Brasilia TIMEZONE_AMERICA_SAO_PAULO 180  0/2/0/3,00:00:00:00 0       0/10/0/3,00:00:00:00 -60     BST          E. South America Standard/Daylight Time

• bias - how many minutes from UTC the time difference is
• stddate - start date for standard time
• stdbias - standard time offset from bias (if applicable)
• dstdate - start date for daylight savings time
• dstbias - DST offset from bias

The key to decoding the stddate & dstdate fields is that the format is day/month/year (not used)/week time. So looking at dstdate for Sao Paulo time above, 0 = Sunday, 10 = October, 0 = ignored, 3 = 3rd week & 00:00:00:00 = 24h time. In other words the clock changes by -60 minutes from normal (i.e. 1 hour ahead) on the 3rd Sunday in October at midnight. Except this year it's not supposed to be until November 4th at midnight & the install I ran the commands against hasn't been patched to update the Olson timezone data.

There's a bunch more useful information in this TechNote.