-
Notifications
You must be signed in to change notification settings - Fork 838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behaviour of moment().local() after moment.tz.setDefault() #258
Comments
Currently, the expected behavior is that There is a bug here though. I would expect See If indeed "local" is defined as "local to the machine", and not "the default time zone which happens to be local when not explicitly set", then calling @timrwood - thoughts? |
Just a cool little addition to this - I think it's basically the same issue. moment.tz('2016-05-03T22:15:01+02:00', 'Europe/Berlin').local().format()
"2016-05-03T15:15:01-05:00"
moment.tz('2016-05-03T22:15:01+02:00', 'Europe/Berlin').local().add(6, 'months').format()
"2016-11-03T15:15:01+01:00" Timezone appears to clear, but the minute you mutate the moment and UpdateOffset runs, back to the original timezone. |
I believe this will be addressed if moment/moment-rfcs#1 is adopted. |
How would one get back to the "default" timezone from a utc one?
Do we have a ??
|
I think this is a bug in moment.js, but before I post there I wanted to get your opinion on it.
After setting the default timezone, subsequent calls to moment() create moment objects in that timezone, whereas the behaviour before that is that moment() creates objects in whichever local timezone. Shouldn't it then follow that after setting a default timezone, subsequent calls to moment().local() should convert an object to the default timezone and NOT the local timezone?
Currently, this happens:
The text was updated successfully, but these errors were encountered: