1334798 - Firefox download end times and Lightning alarm times are offset by one our in Turkey (UTC+3) timezone

Status: RESOLVED DUPLICATE of bug 1547992

(Calendar :: Alarms, defect, P3)

Description

[Selim Şumlu]

Attachment: turkey-time.jpg

When I download any file in Firefox, download end time is seen one hour earlier (16:52 instead of 17:52) in Downloads panel.

This also affects Lightning calendar. Alarms are triggered one hour later. (An alarm set for 17:00 will get triggered at 18:00.)

Possible cause: Turkey no longer observes daylight saving time since October 30, 2016. Instead, Turkey will remain permanently set to the UTC+3 time zone and will not return to UTC+2.

To reproduce:
1. Apply all automatic updates to Widows 10 or download the optional update for earlier versions of Windows. See https://support.microsoft.com/en-us/help/3192321/turkey-ends-dst-observance
2. Set timezone to UTC+03 Istanbul.
3. Download any file in Firefox or set an alarm in Thunderbird.

Comment 1

[Nicolas B. Pierron [:nbp]]

Waldo, are you the right person to deal with time-zone issues? Otherwise, would you know who can handle these?

Comment 2

[Jeff Walden [:Waldo]]

If I test a fairly current SpiderMonkey shell, I get this behavior:

js> new Intl.DateTimeFormat("en-US", { timeZone: "America/Los_Angeles", hour: "2-digit", minute: "2-digit", second: "2-digit" }).format(Date.now())
"3:04:08 PM"
js> new Intl.DateTimeFormat("en-US", { timeZone: "Asia/Istanbul", hour: "2-digit", minute: "2-digit", second: "2-digit" }).format(Date.now())
"2:04:08 AM"

Meanwhile https://www.google.com/search?q=time+in+istanbul and the GNOME applet on my system say 2:04:08 AM.  And consulting an information source that has a chance of being out of date, I get 1:04:08 AM as the time.  So I *think* in-development Firefox gets this right now.  I think?  Selim, could you download a nightly build https://www.mozilla.org/en-US/firefox/channel/desktop/ and see if the issue appears there?

We *have* been updating time zone information that ships with the browser in recent versions (e.g. bug 1314920), but we haven't simultaneously been updating it on branches.  (Although we have backported one or two updates, just not consistently.)  Was the Turkey DST change something new that (say) the Turkish legislature recently created, i.e. in the past there wouldn't have been a DST change in October?  Lack of tzdata update would therefore explain this bug's existence.

Also CCing André who's been doing the tzdata updates lately.

Comment 3

[bgxx]

Maybe a related issue, I am using Thunderbird/Lightning extension and I am always correcting the file "zones.json" manually after each update of Lightning extension. The corrected records are as follows;

Old and wrong lines:

    "Asia/Istanbul": {
      "ics": "BEGIN:VTIMEZONE\r\nTZID:Asia/Istanbul\r\nBEGIN:DAYLIGHT\r\nTZOFFSETFROM:+0200\r\nTZOFFSETTO:+0300\r\nTZNAME:EEST\r\nDTSTART:19700329T030000\r\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU\r\nEND:DAYLIGHT\r\nBEGIN:STANDARD\r\nTZOFFSETFROM:+0300\r\nTZOFFSETTO:+0200\r\nTZNAME:EET\r\nDTSTART:19701025T040000\r\nRRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU\r\nEND:STANDARD\r\nEND:VTIMEZONE",
      "latitude": "+0410100",
      "longitude": "+0285800"


    "Europe/Istanbul": {
      "ics": "BEGIN:VTIMEZONE\r\nTZID:Europe/Istanbul\r\nBEGIN:DAYLIGHT\r\nTZOFFSETFROM:+0200\r\nTZOFFSETTO:+0300\r\nTZNAME:EEST\r\nDTSTART:19700329T030000\r\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU\r\nEND:DAYLIGHT\r\nBEGIN:STANDARD\r\nTZOFFSETFROM:+0300\r\nTZOFFSETTO:+0200\r\nTZNAME:EET\r\nDTSTART:19701025T040000\r\nRRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU\r\nEND:STANDARD\r\nEND:VTIMEZONE",
      "latitude": "+0410100",
      "longitude": "+0285800"


Corrected lines:

    "Asia/Istanbul": {
      "ics": "BEGIN:VTIMEZONE\r\nTZID:Europe/Istanbul\r\nBEGIN:STANDARD\r\nTZOFFSETFROM:+0300\r\nTZOFFSETTO:+0300\r\nTZNAME:TRT\r\nDTSTART:19700101T000000\r\nEND:STANDARD\r\nEND:VTIMEZONE",
      "latitude": "+0410100",
      "longitude": "+0285800"

    "Europe/Istanbul": {
      "ics": "BEGIN:VTIMEZONE\r\nTZID:Europe/Istanbul\r\nBEGIN:STANDARD\r\nTZOFFSETFROM:+0300\r\nTZOFFSETTO:+0300\r\nTZNAME:TRT\r\nDTSTART:19700101T000000\r\nEND:STANDARD\r\nEND:VTIMEZONE",
      "latitude": "+0410100",
      "longitude": "+0285800"



I am not sure whether this correction is fully O.K. or not but it works for me. 

Please note that, last year (2016) there is a new legislation in Turkey, the time zone is fixed as UTC+3 and there is no Daylight Saving Time anymore.

Comment 4

[Selim Şumlu]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #2)
> If I test a fairly current SpiderMonkey shell, I get this behavior:
> 
> Meanwhile https://www.google.com/search?q=time+in+istanbul and the GNOME
> applet on my system say 2:04:08 AM.  And consulting an information source
> that has a chance of being out of date, I get 1:04:08 AM as the time.  So I
> *think* in-development Firefox gets this right now.  I think?  Selim, could
> you download a nightly build
> https://www.mozilla.org/en-US/firefox/channel/desktop/ and see if the issue
> appears there?
I was already on Nightly when filing this bug and the issuee still appears on the latest build.

> Was the Turkey DST change something new that (say)
> the Turkish legislature recently created, i.e. in the past there wouldn't
> have been a DST change in October?  Lack of tzdata update would therefore
> explain this bug's existence.
Indeed, it was. In the past, we would end DST in October and turn back one hour to UTC+2. We're not doing this any more and we'll remain in UTC+3 instead.

Please see this news piece: https://www.timeanddate.com/news/time/turkey-scraps-dst-2016.html

In summary: Turkey will no longer observe DST. Turkey's base timezone was changed from UTC+2 to UTC+3.

Comment 5

[André Bargull [:anba]]

Moving to "Internationalization" component.

This is an issue in nsScriptableDateFormat::FormatTime. FormatTime [1] uses 1999 as a place-holder year and in 1999 Turkey was still UTC+2. 

[1] https://dxr.mozilla.org/mozilla-central/rev/1fe66bd0efba89df59d2046e8c91418eb5ae10b8/intl/locale/nsScriptableDateFormat.cpp#45-46

Comment 6

[Makoto Kato [:m_kato]]

It this still reproduced? We have moved to ECMA-402 API from old time date code, so I think this is fixed.

Comment 7

[Selim Şumlu]

I can confirm that it's fixed in Firefox.

I'm not sure about Lightning/Thunderbird though. None of the testing reminders I created set off. I'll need to investigate why.

Comment 8

[Makoto Kato [:m_kato]]

Thanks, moving product to calendar.

Comment 9

[Selim Şumlu]

FYI: I've already filed bug 1547992.