0

Shorthand Summary: What is the best way / best practice to take in a Timezone purely via text-based user input? Am I attempting a very sticky task?

Background is: I'm working on a nodejs chatbot that is meant to be able to help schedule events for a group that is mostly based in North America, but has participants from around the globe as well. I am able to listen to various user input and respond accordingly. However, other than the user name, the API available to me does not return anything else.

My command input is planned to look like the following:

!Event datetime="MM-DD-YYYY h:mm a" timezone="PST" name="Foobar"

Through moment I am able to parse a moment with the datetime. However, I am failing on applying the timezone. My clients are generally unfamiliar with the UTC/GMT system. Most of them are based in NA or EU, and are more used to abbreviations. I want to make this as user friendly as possible, but how would I map their timezone input to a tz database style for use within the code? I could redirect them to the wiki page regarding the tz database and all the various cities, but it's quite a large list that isn't very user friendly to the average joe.

I am experimenting with moment-timezone, and the closest thing I have is basically a mapping table of UTC offsets to a description + a tz database name. Something like:

var TIMEZONE_MAPPINGS = {
    "UTC+9" : "Asia/Tokyo",
    ...
    "UTC-8" : "America/Los_Angeles",
}

But I feel this is very hackish, and not really good for DST either while I am selecting a "well known" item for each offset.

Is there a better way to take in input like this? Or should I just give up and take in everything via UTC and have an explanation on what UTC is?

Lyr Lunace
  • 3
  • 3
  • is it possible to pass the users' browser timezone to the chatbot http://stackoverflow.com/questions/1091372/getting-the-clients-timezone-in-javascript and not have to input the timezone at all? – Detect Oct 13 '15 at 20:07
  • Unfortunately I cannot access that information. I have a listener that gets a message object, then parses it into: {user: , content: , timestamp (in utc epoch): } – Lyr Lunace Oct 13 '15 at 20:29

1 Answers1

1

You should only take in a tzdb zone id, such as "America/Los_Angeles"

  • Abbreviations won't work, because abbreviations can be ambiguous. Consider there are 5 different meanings of "CST", including China Standard Time. See more on Wikipedia.

  • Offsets or mappings from fixed offsets wont work, because "Time Zone != Offset". See the timezone tag wiki here on StackOverflow.

    In particular, consider that "America/Los_Angeles" is only UTC-8 for part of the year, when it's in Pacific Standard Time. The other part of the year, during the summer, it is UTC-7 for Pacific Daylight Time.

    Additionally, consider that UTC+9 is observed in several places, not just "Asia/Tokyo". For example, "Asia/Yakutsk" uses it all year, but "Asia/Ulaanbaatar" uses it only during the summer.

From the command line, there really is no better choice than a raw identifier. If you had some sort of UI then you could prompt for localized selection, but there's not much else you can do with a raw command line.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • That's what I would LIKE to do, except I don't think my users will know all of those unless I am able to provide them with a reference sheet, which goes against the usability. – Lyr Lunace Oct 13 '15 at 19:16
  • Alright, I guess there's no avoiding that then. Thanks for clearing it up for me!. – Lyr Lunace Oct 13 '15 at 23:48
  • You could always point your users at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones – Matt Johnson-Pint Oct 14 '15 at 18:59