1. Jon Nylander
  2. jsTimezoneDetect
  3. Issues

Issues

Issue #7 wontfix

Hit Stockholm instead of Berlin

Anonymous created an issue

//I am keeping this issue reported by Timo around since it contains a conversation about why this issue will not be fixed. jsTimezoneDetect will not do geolocation in the foreseeable future. (Jon)//

I think there is a way to get the timezone more specifically. Now the code is such that we can determine only 7 of +2:00 zones. The total number of zones is 34:

  • Africa/Johannesburg
  • Africa/Lubumbashi
  • Africa/Maputo
  • Africa/Tripoli
  • Africa/Harare
  • Africa/Lusaka
  • Africa/Blantyre
  • Africa/Kigali
  • Africa/Gaborone
  • Africa/Bujumbura
  • Africa/Maseru
  • Africa/Mbabane
  • Asia/Gaza
  • Asia/Beirut
  • Europe/Minsk
  • Europe/Kaliningrad
  • Europe/Istanbul
  • Europe/Bucharest
  • Europe/Zaporozhye
  • Europe/Kiev
  • Europe/Athens
  • Europe/Sofia
  • Europe/Helsinki
  • Europe/Uzhgorod
  • Europe/Simferopol
  • Europe/Vilnius
  • Europe/Chisinau
  • Europe/Riga
  • Europe/Tallinn
  • Asia/Nicosia
  • Asia/Damascus
  • Asia/Amman
  • Asia/Jerusalem
  • Africa/Cairo

For example in Finland the code produces now Europe/Istanbul, which is annoying for us Finns. And people in Sweden doesn't want to be in Europe/Berlin, they want to be in Europe/Stockholm. We can easily get the daylight savings history by $ zdump -v Europe/Stockholm or by PHP

{{{

!php

$timezone = new DateTimeZone("Europe/London"); $transitions = $timezone->getTransitions(); }}}

In either way we can find the time when daylight savings at all started first time in each and every timezone. In Finland the first time was Thu Apr 2 22:00:00 1942 UTC. In Sweden the first start was Sun May 14 22:00:00 1916 UTC.

We can nearly surely find a time when Europe/Helsinki was in DST, and others not. If not by checking the DST start dates, but checking also by DST end dates. The advantage of this approach to check past days (opposed to future dates) is that they don't change. The update is only needed when A) new timezones are created or B) the name of timezone changes or C) the historydata of some timezone's transitions is changed

what thoughts this approach raises?

Timo

Comments (12)

  1. Anonymous

    Please check in various browsers: http://www.kahkonen.com/loc/dst.html

    I tested it with using OS current timezone Europe/Helsinki. Opera says that DST has been in use every year between 1901-2011.

    Chrome says that DST has been in use in years 1901-1969 and not in use 1970-1980 and again in use between 1981-2011.

    Firefox has more changes in period 1901-2011, but they differ from "zdump -v Europe/Helsinki".

    Safari says, like Opera.

    Every browser has different DST transition history between years 1901-2011. So it seems to be unpossible to test days in the past. The most reliable seems to be current year (where all browsers gave identical results), but in 1981 there were 1-2 hours difference between browsers.

    I have no idea, where browsers get the DST transition history. If it is some common file/files in OS, then browsers interpret it different ways which make it unpossible to reliably handle dates that are in the past.

    Timo

  2. Jon Nylander repo owner
    • changed status to open

    Great investigation Timo, and I do believe that there is a place for that type of exactness. But I don't think it is in JavaScript. If you really want to be able to tell the difference between Europe/Helsinki and Europe/Istanbul I think using straight up IP-mapping is a better way to go.

    I believe the aim of this project, is to get a reliable enough timezone to do server side datetime normalizations. Not to find the exact timezone that the user is in. I am happy with getting "Europe/Istanbul" instead of "Europe/Helsinki". To the user I will simply display "Eastern European Time".

    And for all the +1 timezones that resolve to "Europe/Berlin" - I will simply show "Central European Time". For nearly all practical purposes in a web application, Europe/Berlin and Europe/Stockholm are the same, even though there are historical differences I am pretty sure that nobody in a modern web application is going to work with dates in the beginning of the previous century.

    You are correct however that the rules for DST and zones need to be updated, or at least checked yearly. I am going to start looking into automatically generating the rules. The preferred solution in my mind is to fetch the rules from a service via for example JSON.

  3. Anonymous

    I have faced many combinations when checking transition-data in php. In the following 0 means standard time (winter) and 1 means daylight savings time (summer). First 0/1 means situation in January 1st and the rest are transitions during year.

    • 1 0 1 (summer winter summer, South hemisphere)
    • 0 1 0 (winter summer winter, North hemisphere)
    • 1 0 (summer winter, should be South)
    • 0 0 (winter winter, should be North)
    • 0 1 (winter summer, should be North)
    • 1 1 (summer summer, this I haven't found yet)
    • 1 (summer, America/Argentina/San_Luis in year 2010)
    • 0 (winter, this I haven't found yet)
    • 1 1 0 1 (summer - summer - winter - summer, This is America/Argentina/San_Luis in year 2008, very odd year)
    • 0 1 0 1 0 (Africa/Cairo 2010)

    And we should get the right transition time among these!

    Timo

  4. Anonymous

    1 1 0 1 (Timezone: America/Argentina/San_Luis 2008)

    Also year 2008 was very odd in San_Luis. Year started with dst in effect and the offset was -7200 and then the offset changed several times during year 2008:

    time:2008-01-01T00:00:00+0000 offset:-7200 isdst:1 abbr:ARST

    time:2008-01-21T02:00:00+0000 offset:-10800 isdst:1 abbr:WARST

    time:2008-03-09T03:00:00+0000 offset:-14400 isdst:0 abbr:WART

    time:2008-10-12T04:00:00+0000 offset:-10800 isdst:1 abbr:WARST

    Which one dst-start-time to pick in this case? 2008 last dst-start or 2007 last dst-start? Maybe it is the same which one. Main thing is to find a date that is in near history or near future.

    Bigger problem is to get the non-dst offset in this case. The non-dst offset we need to find a proper "main" zone. Should we pick as a "main" zone -14400 or find proper one in year 2007?

    Timo

  5. Jon Nylander repo owner

    I think we should try to find timezones which are readily available to set as a timezone on the operating system. That should be the focus, rather than trying to solve edge cases.

    When the timezone is extremely obscure (like America/Argentina/San_Luis) and when you need to know shell commands to set the timezone they are not extremely interesting in my mind.

    The aim of this script is to find a "good enough" timezone. Either you can trust the script or you can choose to actually ask the user ("We have auto-detected your timezone to Africa/Gaza, click here to modify if you feel it is wrong").

  6. Anonymous

    "Good enough" is right. The detection quality suffer if there are some Antartica zones, because they are not implemented in users machines. However in some cases people have to make modifications. Eg. Windows has not enough zones and Microsoft has tool for updating zonedatabase and instructions how to change manually timezone.xml file. Many really normal users suffer from the lack of timezone or poor quality of dst-information on their machines and OS developers are now answering to these needs.

    Timo

  7. Log in to comment