1. Jon Nylander
  2. jsTimezoneDetect
  3. Issues

Issues

Issue #74 new

Asia/Dubai detection in Europe/Moscow zone [revisited]

Vsevolod Golovanov
created an issue

I saw Issue #63 and the decision is a bit unclear to me.

The documentation says the following: "the scope of this script is to solve problems concerning modern time zones, in this case from 2010 and forward".

Russia abandoned winter time in 2011. That means there were winter/summer time switches in 2010 and 2011. If the user inputs a date in a winter of 2010 or 2011, it will be normalized wrongly, if the server uses incorrectly detected Asia/Dubai timezone. Is this not a valid use case for this script?

Comments (4)

  1. Matt Johnson

    This is one of the cases that is hard to detect due to issue #68. For example, set your computer's time zone to Moscow and run this in your web browser's Javascript console:

    new Date(2011,2,1,3).toISOString()
    

    In most environments, it will incorrectly report 2011-02-28T23:00:00.000Z. It should report 2011-03-01T00:00:00.000Z.

    Since this would be the kind of query that jsTimeZoneDetect would rely on to distinguish one type from another, it's impossible to tell them apart.

  2. John Babak

    Could it be possible if you call a hook for the user code to provide ambiguity resolution if it cannot be resolved reliably by the library? This ambiguity resolution could check language or geo-IP. You could provide basic language check bundled with the library.

  3. Log in to comment