Issues

Issue #6 resolved

Automatic timezone-list generation and shortened get_date_offset()

Anonymous created an issue

As we can see, the timezone-data changes every year (sometimes every month). I made a helper script for generating data-lists for this detection library:

When we compare different years, the data is living: http://www.kahkonen.com/loc/timezones_by_population3.php?year=2008

http://www.kahkonen.com/loc/timezones_by_population3.php?year=2011

Script makes good results in 2011 (all timezones passed in Safari and Firefox made one failure), but 2008 there are duplicates, due to my poor coding skills:

'-240,1,s' : new TimeZone('-04:00','America/Argentina/San_Luis', true),

'-240,1,s'  : new TimeZone('-04:00','Atlantic/Stanley', true),

Maybe I find the bug in my code that makes 2008 duplicates and this script can be as helper when updating detection code.

I hope, Jon, that this tool is for help to you and other users. If you think it violates your rights or something, please inform me and I get the tool offline.

In that link I provide also shortened version of the following function:

function get_date_offset(date) {

return -date.getTimezoneOffset();

}

Timo

Comments (11)

  1. Jon Nylander repo owner

    Thanks for the shortened get_date_offset().

    One question for you to think about. Isn't it enough to know DST start times for for example 2011? Even if the "real" year is something else, we check DST start times as they were in 2011 to find out the user's timezone.

    For example, if the real year is 2013. And we want to find out in which +2 timezone we are in (Gaza or Beirut or Istabul etc), we can simply create dates in javascript for 2011 and the browser should supply us with the correct data, as the rules were back in 2011.

  2. Anonymous

    If there comes new dst start that should be for example between these two:

    'Europe/Istanbul' : new Date(2011, 2, 27, 4, 0, 0, 0),

    'Asia/Damascus' : new Date(2011, 3, 1, 1, 0, 0, 0),

    If for example +02:00 zone Europe/Bucharest is going to start observe dst 2013-28-03 00:00:00 and user has Europe/Bucharest as his OS timezone and current time is April 2013. Javascript tests existing dates in the list and when testing start date of Asia/Damascus, it snaps. If we update our list before dst starts in Europe/Bucharest, then the detection snaps to Europe/Bucharest. Otherwise Bucharestians are detected to be in Asia/Damascus. This is not good example, but there are areas in the world that changes dst start time yearly basis or decides to not to introduce dst at all.

    So, I think yearly checking is needed to be reliable.

  3. Anonymous

    In the previous example I assume that example zone Europe/Bucharest has previously (before example date 2013-28-03) had other dst start or not start at all.

    In the case that none of the dst rules of the world does not change, the update of detection code is not needed and the detection in the future will succeed. But if there comes changes, the changes shall be added to code.

  4. Anonymous

    I have to be more specific in the above example. If Europe/Bucharest has not observed dst in 2011 and the detection list has start dates of 2011, then Europe/Bucharest snap to the equivalent +02:00 non-dst zone, which is Africa/Johannesburg. But if Europe/Bucharest has had 2011 dst start some other time, for example the same than Asia/Damascus, then it snaps. So I think that if the dst start times change, the list has to be updated.

    If somebody think I'm wrong, please correct me.

  5. Anonymous

    I try to find the bug in my code, so that this tool can be used as update source without manual work. (Of course I have to update timezonedb of my server regularly). My code is this time only a helper tool, as it is tested only 2011 dates.

    Because in my thoughts update is essential to be up to date, some sort of server work is needed. The javascript is needed mainly to get the users utc-offset in specific dates (january and june). If these two offsets are sent to server, the server can make a dirty work of examining the Olson id. And the server can easily be updated by newest timezone database.

    If being only javascript side, the update process has to be done manually or make some javascript-wrapper that reads timezone database, which is on server. The server seems to be essential. But who needs Olson id locally? It is usually needed by server to change times between client and server.

  6. Anonymous

    I think when using my shortened version of get_date_offset(), the DST start times should be in timezone's local time +1:00 hour. Now in your code all the times are not +1:00.

  7. Anonymous

    This is said before, but let's say it again. Browsers knowledge of transitions has huge effect to the detection quality. I assume that browsers blow away past transitions. So if we rely 2011 dst start dates or other transitions 2013, only few of browsers have stored so the old information. This is unintelligible, because

    new Date(some_date_in_the_past)
    

    gets wrong if the browser has no idea what is the real UTC offset on that date.

    Timo

  8. Jon Nylander repo owner

    I'm not sure browsers blow away their knowledge of timezones and past dates. I think they base their knowledge on the operating system's zoneinfo. And this implementation varies from OS to OS. Usually zoneinfo goes back to at least 1970.

    However, on an unupdated operating system the zoneinfo files may be too old, and may not know about DST-transitions in Jerusalem in 2011. That is a problem to be aware of.

    I agree that as the maintainer of this project I will have to update the detection script from time to time, and perhaps provide detection separately, as a javascript API for example.

  9. Log in to comment