Issue #2 resolved

Safari detects different timezone than other browsers

Anonymous created an issue

When I tested detection script with Safari, the result in my timezone is Europe/Minsk, but with all other browsers (Chrome, Firefox, Opera, IE) it is Europe/Helsinki, which is the right one.

I examined the problem, and noticed that when ambiguity_check()-function tests dates of local_ambiquity_list using date_is_dst(date), Safari behaves differently. The "Asia/Beirut"-list first value is "Europe/Minsk", and date_is_dst(dst start date of Europe/Minsk) evaluates true in Safari, but false in other browsers. In date_is_dst()-function the date_offset in Safari is 180, while all other browsers it is 120. When I tested Math.abs(date2.getTimezoneOffset()) all browsers returned the right value 120. Why not to use getTimezoneOffset()?

dst_start_dates are not real, why? In Europe/Helsinki the start time is 03:00 local time (= UTC 01:00), and Europe/Minsk the start is 02:00 local time (= UTC 00:00). I don't understand why the times in the following are 05:00:00 and 07:00:00:

'Europe/Minsk' : new Date(2011, 2, 27, 5, 0, 0, 0) 'Europe/Helsinki' : new Date(2011, 2, 27, 7, 0, 0, 0)

Timo, Finland

Comments (9)

  1. Anonymous

    I succeeded in detectioning with minor code changes. I Changed all +02:00 dst timezones so that the hour is +4 hours after dst start (On Europe/Helsinki dst starts 03:00, so the value will be 07:00, On Asia/Beirut start is 00:00, so the value will be 04:00). And I ordered zones by dst start date ascending. Asia/Beirut was third although there dst comes first.

    'Asia/Beirut' : new Date(2011, 2, 27, 4, 0, 0, 0), 'Europe/Minsk' : new Date(2011, 2, 27, 6, 0, 0, 0), 'Europe/Helsinki' : new Date(2011, 2, 27, 7, 0, 0, 0), 'Asia/Amman' : new Date(2011, 3, 1, 4, 0, 0, 0), 'Asia/Jerusalem' : new Date(2011, 3, 1, 6, 0, 0, 0), 'Africa/Cairo' : new Date(2011, 3, 29, 4, 0, 0, 0),

    I reordered also this list (by dst start time ascending): OLD: 'Asia/Beirut' : ['Europe/Minsk', 'Europe/Helsinki', 'Asia/Beirut', 'Asia/Amman', 'Asia/Jerusalem','Africa/Cairo'], NEW: 'Asia/Beirut' : ['Asia/Beirut', 'Europe/Minsk', 'Europe/Helsinki', 'Asia/Amman', 'Asia/Jerusalem','Africa/Cairo'],

    And the final change: OLD: var utc_offset = (date - date2) / (ONE_HOUR_IN_MINUTES); NEW: var utc_offset = -date2.getTimezoneOffset();

    With these modifications I tested the script with Windows XP (Firefox, IE, Chrome, Safari) and Mac OS X (Firefox, Chrome, Safari, Opera). All browsers newest versions or maximum half year old. I changed Windows Date and Time Settings timezone between all six +02:00 zones and all tests with all those browsers passed.

    I have to test also other timezones that have ambiguities.

  2. Anonymous

    Baku and Yerevan dst start times seemed to be wrong (at least when using "var utc_offset = -date2.getTimezoneOffset();". All other ambiquity zones were right according to my tests.

    OLD:'Asia/Yerevan' : new Date(2011, 2, 27, 4, 0, 0, 0), 'Asia/Baku' : new Date(2011, 2, 27, 9, 0, 0, 0),

    NEW: 'Asia/Yerevan' : new Date(2011, 2, 27, 8, 0, 0, 0), real start 02:00 'Asia/Baku' : new Date(2011, 2, 27, 10, 0, 0, 0), real start 04:00

    I have not yet got the idea of real dst start times vs. these start times. On +02:00 dst zones the addition is 4 hours and on these +04:00 zones 6 hours. The algorithm seems to be real_dst_start_time + UTC_offset + 2. The algorithm is important, because dst rules used to be changed in future and the code is valid only maybe several months. - Timo, FI

  3. Anonymous

    Pacific/Pohnpei is nowadays Pacific/Ponape.

    I think Fiji has only dst timezone, so +12:00 non-dst should be some else than Pacific/Fiji for example Pacific/Nauru, Pacific/Wallis, Pacific/Wake, Pacific/Majuro or Pacific/Funafuti.

    This is a detail but there is also other :45-zone than Kathmandu, it is: '765,1,s' : new TimeZone('+12:45','Pacific/Chatham', true) which should be nice addition for all Chathamians:)

    -Timo, FI

  4. Anonymous

    I found still one :45-zone:

    '525,1,s' : new TimeZone('+08:45','Australia/Eucla', true)

    -Timo, FI

  5. Jon Nylander repo owner

    I don't know what to say. You must be the best tester ever. I don't have time to implement your changes today but I will do so on Monday. Great work! Thank you so much!

  6. Jon Nylander repo owner

    Again, thanks for the investigation and the corrections. The +2 timezone is probably the most complicated of them all. I am a little thrown off by you finding two more +45 timezones though. I can't even find a way to set these timezones in my operating systems, neither in OSX or in Windows. :D

    I've added Australia/Eucla and Pacific/Chatham. Changed +12 non-dst to Pacific/Wake. And changed the +2 timezone according to your investigation.

  7. Log in to comment