3

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?

  • the time you are working with is UTC - there is no useful information in a UTC time as to what the original timezone was, as it could've been absolutely anything - sometimes when dealing with dates/times it's just far easier to use strings (in my opinion) – Jaromanda X Nov 30 '16 at 22:15
  • 2
    A date and time is just a date and time. There's nothing about that data which would identify it as originally coming from a given timezone. You'll need to look into how you get that data in the first place and gather the timezone information from there. – Mike Cluck Nov 30 '16 at 22:15
  • That's why I provided the context about how the timestamp is generated. If the timestamp is not in daylight savings time, it returns the timestamp, otherwise it returns the timestamp plus 1 hour offset. Given this information, I suspect that there is a way to guess the original timezone for at least some cases. –  Nov 30 '16 at 22:21
  • 1
    @K.R.S. A lot of places have daylight savings time. That isn't restricted to the east coast. In order to identify the original timezone, you would need one or more pieces of information which correlate with that timezone. The only information you have is the date, time, and a DST offset. That is not enough information to uniquely identify *any* timezone. – Mike Cluck Nov 30 '16 at 22:23
  • 1
    @K.R.S. Re: your edit. Imagine someone from CST submits data on the same date but appears to be one hour earlier than someone in EST. The data you receive on the front-end will be equal to the one you got from someone in EST an hour later. – Mike Cluck Nov 30 '16 at 22:30
  • @Mike C I have updated the question to be more clear about the problem I am trying to solve. –  Nov 30 '16 at 22:58

1 Answers1

4

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:

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Thanks for the feedback. I have changed the wording of timezone to timezone abbreviation. Although timezone abbreviations can be ambiguous, in this case there exists a well defined mapping from timezone abbreviation to UTC offset. I am not able to change anything related to the backend, so this table must be used, and same with the fixed 1 hour offset for DST. –  Nov 30 '16 at 22:45
  • Is this world-wide? If so, what did you put for `MSK`? – Matt Johnson-Pint Nov 30 '16 at 22:45
  • 2
    BTW - I also suggest you watch: https://www.youtube.com/watch?v=-5wpm-gesOY – Matt Johnson-Pint Nov 30 '16 at 22:48
  • This is not world wide, and MSK is not a selectable option. I have edited the question to make it more clear what I am asking, and changed the date to one that is actually in daylight savings time. –  Nov 30 '16 at 22:55
  • 2
    Yes. I'm reading your edits. It's still not clear what you're asking. Originally you asked how to get back to a time zone. Now you appear to be asking if there's a way to disambiguate when you don't have all the information. In both cases, the answer is no. Also - you say it is not worldwide, but actually it would be quite helpful to know exactly what the geographical scope of your application is. – Matt Johnson-Pint Nov 30 '16 at 23:00
  • 2
    I'll give you another problem you may have not considered. Say you were given `MST` as an input. That's UTC-7 in the US. But now you want to know whether or not DST is in effect so you can switch to UTC-6 - except that most of the state of Arizona remains in `MST` and doesn't use DST at all. You have the same problem with `HAST` (UTC-10), because the Aleutian Islands in Alaska do use DST, but Hawaii does not. – Matt Johnson-Pint Nov 30 '16 at 23:03
  • 4
    At the end of the day the answer is - no. Sorry. You can't. Not unless you want to be wrong in very many edge cases. – Matt Johnson-Pint Nov 30 '16 at 23:04
  • Ok, I see now that the timezone abbreviations are overcomplicating things, so I have removed them and directly used the UTC offset mappings. Regarding scope, the allowed UTCS offsets that can be selected are every hour offset from UTC-05:00, UTC-06:00... UTC-09:00, UTC-10:00. It's ok to be wrong in many edge cases, I am just interested in which edge cases can be disambiguated. –  Nov 30 '16 at 23:10
  • For example, UTC-04:00 can be disambiguated since it is not allowed to be selected. So if I see UTC-04:00 I can be sure it was originally UTC-05:00 and underwent the DST transform regardless of if the timestamp lies on a DST boundary. I am looking for hacks like this, and can provide any other information needed for disambiguation. –  Nov 30 '16 at 23:13
  • 1
    No, it cannot be done. It seems you need even more examples to convince you. Consider `2016-06-01T00:00:00-07:00`. Is that Pacific time adjusted for daylight saving? Or is that Mountain Time in Arizona where DST does not occur? There's no way to tell. – Matt Johnson-Pint Nov 30 '16 at 23:26
  • @MattJohnson Excellent answer, but I would add one more point: **Use UTC.** If the source and sink of this data exchange had been exchanging UTC values, all of the problems go away. – Basil Bourque Dec 01 '16 at 07:24
  • @Basil Bourque I don't see how using UTC would help as UTC does not contain any UTC offset information, which is the part that I am interested in. –  Dec 01 '16 at 07:47
  • From UTC you can adjust into any desired offset-from-UTC or into any desired time zone. Generally the best practice is to work in UTC as much as possible, especially for data exchange. In Java, that means Instant is the basic class to use often. Apply a ZoneId to an Instant to get a ZonedDateTime. – Basil Bourque Dec 01 '16 at 07:52
  • @Matt Johnson In that case, since that date and time lies within DST and not on a DST boundary, I know that the user originally provided it as `2016-06-01T00:00:00-08:00`, which was modified by the backend into `2016-06-01T00:00:00-07:00`. So I would display `-08:00`. I only used UTC offsets to avoid confusion, but when the data is entered, there is no concept of whether DST occurs or not. The user selects "Pacific time" which is mapped to `-08:00` regardless of if it is Pacific Standard or Daylight Time. –  Dec 01 '16 at 07:56
  • @Basil Bourque I do not want to adjust into any desired offset from UTC. I want to keep the original offset from UTC that the user enters. As far as I know, that information is lost in the conversion to UTC. Am I overlooking something? –  Dec 01 '16 at 07:59
  • @K.R.S. No where in your Question did you say anything about "I want to keep the original offset that the user enters". – Basil Bourque Dec 01 '16 at 08:07
  • @Basil Bourque I mentioned that "Finally, I receive that string in the frontend (javascript), and I need to make it display the original UTC offset -05:00", but I will edit this to make it more clear. –  Dec 01 '16 at 08:09
  • 1
    Ok, so you adjust it to `-08:00`. Then your user complains because he's in Arizona. It's always `-07:00` there. – Matt Johnson-Pint Dec 01 '16 at 23:00
  • @Matt Johnson Well, as I said I used UTC to avoid confusion with timezone abbreviation but actually the user enters PST, which is mapped to `-08:00`, which is given to the frontend as `-07:00`, which I guess to actually be `-08:00`, so I display PST, which matches what the user entered. The goal is not to match the user's local timezone but whatever the user chose to enter originally. –  Dec 02 '16 at 20:47