K.R.S. K.R.S. - 8 days ago 5
Javascript Question

How to guess the timezone of a timestamp?

Context:

A user provides a date and time, along with a specific UTC offset

1994-06-05T08:15:30-05:00


This is then passed through some Java datetime libraries, which determine that this occurs during daylight savings time, and helpfully adds an hour to the offset (if the timestamp is not in daylight savings time, it is returned without modification):

1994-06-05T08:15:30-04:00
(Note that the time of the day
15:30
is NOT changed)

Finally, I receive that string in the frontend (javascript), and I need to display only the original UTC offset exactly as it was entered,
-05:00
in this case.

I cannot change any parts of the process leading up to this point, so my only option is to try to reverse engineer the daylight savings time detection, and subtract an hour of offset when appropriate.

Since the date and time of day remain unchanged, an obvious solution is to just check
IF date and time are in daylight savings time THEN subtract one hour from offset
. For the majority of timestamps this works, however there are problems at the DST boundary, since for example the same timestamps can occur twice from 1am to 2am the day the DST goes into effect. Is there any method I can use to disambiguate some or all of the timestamps that occur at the DST boundary, given the information about how the final timestamp is generated?

Answer

A few things:

  • EST is a time zone abbreviation, not a time zone. A time zone would be identified by it's IANA/TZDB identifier, such as America/New_York.

  • In general, time zone abbreviations should be avoided because:

    • They can be ambiguous. For example, CST could be US Central Standard Time (UTC-6), Cuba Standard Time (UTC-5), or China Standard Time (UTC+8).

    • In some parts of the world, they are associated with a region, not a fixed offset. For example, MSK has been used in Moscow, Russia for a very long time. It currently means UTC+3, but for some years in the past it meant UTC+4.

    • Not everyone agrees on the abbreviation to use. For example, Hawaii sometimes is called HST (Hawaiian Standard Time), and is sometimes called HAST (Hawaii-Aleutian Standard Time)

    • Not every place in the world uses English abbreviations, or even uses abbreviations around their time zones at all. Especially if only one time zone applies for the entire country.

  • You said in the back end you mapped EST to -05:00. That means somewhere you have defined a table mapping time zone abbreviation to offset. You will likely find that table to be highly opinionated, and could be volatile as your application is maintained over time. I recommend against this.

  • You said you also determined that because of DST you added an hour. Recognize that DST is done differently all over the world. If all you have is an offset from UTC, you cannot reliably determine whether or not DST is in effect. Also, there is at least one place on the planet (Lord Howe Island, Australia) that switches by 30 minutes for DST, not an hour. Don't make any assumptions.

  • Assuming you mean the US Eastern time zone, on the day you gave, 1994-11-05, Eastern time was on EST (UTC-5). So your example is wrong because you would not move to UTC-4 on this date. If you did, your abbreviation would change to EDT anyway - not EST.

  • You cannot go from offset back to time zone, or to time zone abbreviation, for the ambiguous nature of how offsets are used.

    • UTC-5 could be EST, or it might be ACT, CDT, COT, CST, EASST, ECT, or PET.

    • UTC-4 could be EDT, or it might be AMT, AST, BOT, CDT, CLT, COST, ECT, FKT, GYT, PYT, or VET.

  • Even if you know you are limited to a single country, and you have a single offset, you cannot always tell what time zone that is from, due to the nature of how DST works in some places. For example, 2016-11-06T01:00:00-05:00 in the United States might have been CDT (America/Chicago), or might have been EST (America/New_York). Both were in effect simultaneously.

Please review the following: