1

I am converting all the visitors local times to UTC using momentJs

visitor_utc = moment().utc().valueOf()

and getting the offset like this 

visitor_utc_offset = moment().utcOffset().valueOf() / 60

I would like to have a drop-down list filled with offsets (... -01:00, +00:00, +01:00, +02:00 ....) so the user can change and set his actual offset. The default selected value will be the visitor_utc_offset

Is there any method to get a list of offsets using momentJs ?

With moment-timezone it's possible to do something like that :

for element in moment.tz.names()
    console.log moment.tz(element).format("Z")

But it gives a long list with a redundant values (because I am just formatting the timezones names which can have the same offset)

I also found a list in Wikipedia List_of_UTC_time_offsets But I am just not sure if it's a complete list, and it's reliable for the future ?

UPDATE

To compare the list of offsets used in moment-timezone and the one from Wikipedia I used this code :

  for element in moment.tz.names()
    if $.inArray( moment.tz(element).format("Z"), arr ) <= -1
      arr.push moment.tz(element).format("Z")

Which eliminate all double entries, so I've got an array like this :

["+00:00", "+03:00", "+01:00", "+02:00", "-09:00", "-08:00", "-04:00", "-03:00", "-05:00", "-06:00", "-04:30", "-07:00", "-02:00", "-02:30", "+08:00", "+07:00", "+10:00", "+11:00", "+05:00", "+12:00", "+06:00", "+05:30", "+09:00", "+04:00", "+04:30", "+05:45", "+06:30", "-01:00", "+09:30", "+08:45", "+10:30", "-10:00", "-11:00", "-12:00", "+13:00", "+14:00", "+12:45", "-09:30", "+11:30"]

This array contains 39 offsets, but In Wikipedia there are 40 offsets

So After looking for a while I was able to found that in Wikipedia you can find the offset +03:30 and -03:30 but in the moment-timezone you can't !!

That's a weird thing !?

medBouzid
  • 7,484
  • 10
  • 56
  • 86

1 Answers1

2

Recognize that a time zone is not the same as an offset.

Time zones change offsets based on the whims of governments. Many change for daylight saving time on a regular, semi-regular, or irregular basis. Some have changed base-offsets for other motivations, such as when Samoa jumped to the other side of the international date line.

If you ask for their current offset, then you are not assured that you are using the correct offset for any given point in time. You cannot just pick a point in time and assume that offset is the offset for a particular user.

With regard to your moment code, you're only checking each time zone for it's current offset. There is a history of offset changes represented by each zone, which is not accounted for in your list. You can examine the offsets array within each zone entry to see them.

See also "Time Zone != Offset" in the timezone tag wiki.

The only valid use for a drop-down of offsets is if you are creating a date-time-offset picker. That is, a specific date and time are associated with the specific offset. For example, one might have a form where the local date, time, and offset of a specific event occurs.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • I am aware of TimeZone != Offset, I am considering that my users don't know enough about timezones (I am one of them) bcause they are just normal people, so for them they just want to pick a date in the future based on their current time & location then for all other visitors they will see the time left for that specific date based on their timezone. My idea is to convert the user time on UTC and also visitors time to UTC & I think I can do the subtract easily. the problem will come if the user current offset is +00 when he pick a future date & before that date the offset change – medBouzid Jul 05 '15 at 19:10
  • do you have any better Idea, I think you master time better than most of developers here, so I would like to know your opinion ? – medBouzid Jul 05 '15 at 19:16
  • Future dates are tricky, because you're not necessarily guaranteed that the time zone rules won't change between now and then. Governments don't always give adequate notice to push updates in time, and even when they do you have to account for the differences. Consider if you convert to UTC just to later go back to the same zone, but find that it's now using a different offset because some government official moved their DST start date. – Matt Johnson-Pint Jul 05 '15 at 19:30
  • Usually the best thing there is to have the user specify the event in terms of local time, and actually save the local time. Also have the user choose a time zone (not an offset). If the rules change, the *absolute time* for the event has to change as well, so you need to capture the original intent of the user. – Matt Johnson-Pint Jul 05 '15 at 19:31
  • This is especially important for *recurring* events. – Matt Johnson-Pint Jul 05 '15 at 19:32
  • I've written 5 or 6 times about this in other SO answers. Here's one. http://stackoverflow.com/a/19627330/634824 – Matt Johnson-Pint Jul 05 '15 at 19:33
  • As far as making it easier on your user - consider a *pair* of dropdowns. The first picks the country, the second picks the timezone within the country if there is more than one to choose from. It does take some work to build such a control, but it's quite intuitive. There are also map-based timezone pickers - if you have room in your UI. I've got a demo of both in [my Pluralsight course](http://www.pluralsight.com/courses/date-time-fundamentals) (module 7, section 8, "Time Zone Selection") – Matt Johnson-Pint Jul 05 '15 at 19:34
  • wow thank you for a such explanation I appreciate the help you do here and I even don't know who can help us with time issues if you were not here :) I understand how that is tricky and even if I use some libraries to help me dealing with timezones there are no guarantee that the rules don't change, so I need to be updated every time... what do you think about forcing the user to pick the event date not based on his local but based in a UTC offset (the widget will be a datapicker + dropdown list of UTC) and for the visitors I will get their current UTC offset to do calculation ? – medBouzid Jul 05 '15 at 20:22
  • I am afraid to make a mistake so I want to be sure I am going to do the right thing – medBouzid Jul 05 '15 at 20:25
  • If you explicitly ask the user for the event's date, time and UTC offset, then you aren't claiming to be responsible for offset changes, so that's fine. Just set user expectations accordingly. For example, if you have a daily event at 8:00 am, and the user chooses an offset of -8, then they shouldn't be surprised when the event runs at 9:00 am after the DST transition puts them in -7. If the intent was -8, then you delivered -8. It's just that most users would expect the intent to be "Pacific time", so set expectations accordingly. – Matt Johnson-Pint Jul 05 '15 at 20:41
  • yes this is my Idea I will put a "Warning" at the bottom explaining that. Just to clarify a little bit, I am not planning for meeting event or web live events.. for a such kind of events I prefer to put only a simple (written) date with a (written) timezone, the events I am talking about here will be only a dates to close a discount or to launch a product or to open inscription etc... this is why I think using UTC is enough in my case – medBouzid Jul 05 '15 at 20:49
  • @MattJohnson thanks so much for all your detailed responses to these types of questions. I have read several of your answers, and resources you have supplied. I am wondering if you are aware of a Google Script Library that has the IANA TZDB as a callable resource? Maybe even one that auto updates would be an awesome resource. Thanks again for your time. – Craig Lambie Sep 16 '18 at 16:24