10-25-2016 04:44 AM - edited 03-12-2019 10:24 AM
Introduction:
With the switch from DST to standard timing, we have noticed quite a few customers facing issues where their IP Phones moved from DST to standard time a week in advance.
Currently without the fix, the phones switch to standard timing on 23rd October 2016 which is a week ahead of the actual date ( 30th October 2016 ).
This article intends to provide complete information to our customers from diagnosing to fixing this issue incase they experience it.
Diagnosis:
To determine if we are hitting this issue, the first step is to run an sql query to check the dst date recorded in the database.
admin:run sql select * from typetimezone where name="Europe/London"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ============= ============================================================ ====================== ==== ==================== ======= =================== ======= ============ ==========================
21 Europe/London (GMT) Greenwich Mean Time; Dublin, Edinburgh, London, Lisbon TIMEZONE_EUROPE_LONDON 0 0/10/0/4,02:00:00:00 0 0/3/0/5,01:00:00:00 -60 GMT GMT Standard/Daylight Time
Where:
Here 0/10/0/4 means Month/Day/Week : October/Sunday/4th Week
0/3/0/5 means Month/Day/Week : March/Sunday/5th Week
Therefore per the output, the standard time start date is 0/10/0/4 which is 23rd October, 2:00 am.
This is the reason we would be seeing standard time starting a week before the actual date (30th October).
Fix for the issue:
The latest 2016d cop file includes the fix for this issue. It is available for UCM versions a) 11.5
b) 10.5.2
c) 11.0
d) 9.1.2
Install the cop file on all the nodes in the clsuter, followed by the cluster reboot to resolve the issue.
Verification:
After installing the cop file followed by a cluster reboot the output of the same sql command would look like:
admin:run sql select * from typetimezone where name="Europe/London"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ============= ============================================================ ====================== ==== ==================== ======= =================== ======= ============ ==========================
21 Europe/London (GMT) Greenwich Mean Time; Dublin, Edinburgh, London, Lisbon TIMEZONE_EUROPE_LONDON 0 0/10/0/5,02:00:00:00 0 0/3/0/4,01:00:00:00 -60 GMT GMT Standard/Daylight Time
Where:
Here 0/10/0/5,02:00:00 means Month/Day/Week : October/Sunday/5th Week, 2:00:00 am.
After installing the fix, we see that the Standard time start is 0/10/0/5, which translates to 30th October 2:00 am, which is the right Date.
Download links:
11.5
11.0
10.5.2
9.1.2
NB: If your version of the Call Manager is not listed here, we need to either upgrade to a compatible version and then install the fix or use a timezone which follows the correct time till the 30th of October.
Beautiful my friend!!
I had these problem and I followed your instructions.
Thank you.
Hi,
Sorry to be posting on this old thread but this is the most very helpful thread i found with the issue we are experiencing.
In NZ DST starts on the last Sunday of September. But this year some of the older model of the phones started displaying incorrect time(1 hour ahead) a week earlier. Obviously i suppose this is because of 5 Sundays this month. we applied the latest DST patch and the issue has been resolved. However I have another query regarding this patch. Below 2 outputs are before and after applying the patch. First one has DST starting on 4th Sunday (which is not last Sunday of September this year). The second one has DST starting on 5th Sunday (Which is last Sunday of September this year). My query is, what happens in future when there are only 4 Sundays on the month of September. Year 2019 will probably not be an issue as it has 5 Sundays, but what about the year after that? Would we have to install another DST patch for that, or this output is specific to the query made at a particular date and time?
admin:run sql select * from typetimezone where name="Pacific/Auckland"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================ ================================ ========================= ==== =================== ======= =================== ======= ============ ==================================
51 Pacific/Auckland (GMT+12:00) Wellington, Auckland TIMEZONE_PACIFIC_AUCKLAND -720 0/4/0/1,03:00:00:00 0 0/9/0/4,02:00:00:00 -60 NZST New Zealand Standard/Daylight Time
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
admin:run sql select * from typetimezone where name="Pacific/Auckland"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================ ================================ ========================= ==== =================== ======= =================== ======= ============ ==================================
51 Pacific/Auckland (GMT+12:00) Wellington, Auckland TIMEZONE_PACIFIC_AUCKLAND -720 0/4/0/1,03:00:00:00 0 0/9/0/5,02:00:00:00 -60 NZST New Zealand Standard/Daylight Time
Your feedback will be much appreciated.
Regards
Bhola
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: