moment-timezone
moment-timezone copied to clipboard
Using a default timezone breaks clone() and startOf() functionality with explicit zones
My browser timezone is CET (+01:00/+02:00).
If not setting an explicit default timezone, stuff works as expected:
moment.parseZone("2015-03-03T12:00:00+00:00").format(); //"2015-03-03T12:00:00+00:00"
moment.parseZone("2015-03-03T12:00:00+00:00").clone().format(); //"2015-03-03T12:00:00+00:00"
moment.parseZone("2015-03-03T12:00:00+00:00").startOf("day").format(); //"2015-03-03T00:00:00+00:00"
When setting an explicit timezone, even dates with explicit zones are set to the default zone when cloned or start-of-day'd
moment.tz.setDefault("CET");
moment.parseZone("2015-03-03T12:00:00+00:00").format(); //"2015-03-03T12:00:00+00:00"
moment.parseZone("2015-03-03T12:00:00+00:00").clone().format(); //"2015-03-03T13:00:00+01:00"
moment.parseZone("2015-03-03T12:00:00+00:00").startOf("day").format(); //"2015-03-03T00:00:00+01:00"
According to the documentation, setDefault should only override what the local timezone is; I would expect a browser with moment.tz.setDefault("CET"); to behave the same as a browser where the local timezone is CET. In addition I expect clone() to give me an exact clone of the object, regardless of default timezones. For startOf() I can understand that behaviour may be not what I expect in this case, however I would expect behaviour to be the same with a local CET timezone and an explicit CET default timezone.
Agreed. They're both bugs.
Cloning a moment shouldn't change anything about it. Any mode, offset, or zone details should carry forward.
With regard to startOf('day'), I would expect that whenever you set an offset explicitly (via parseZone, or utcOffset), that the moment is locked into a "fixed time zone" with that offset. It shouldn't assume any of the DST rules for the default time zone - regardless of whether that's the implicit "local" zone, or whether it's explicitly set with moment.tz.setDefault.
Therefore, I would expect:
moment.parseZone("2015-03-03T12:00:00+00:00").startOf("day").format() === "2015-03-03T00:00:00+00:00"
However, I would expect it to use the time zone rules had you not called parseZone (even if an offset was in the string).
moment("2015-03-03T12:00:00+00:00").startOf("day").format() === "2015-03-03T00:00:00+01:00"
Consider that without moment-timezone, setting my time zone for Brazil:
moment("2014-10-19T12:00:00+08:00").startOf('day').format()
// "2014-10-19T01:00:00-02:00"
moment.parseZone("2014-10-19T12:00:00+08:00").startOf('day').format()
// "2014-10-19T00:00:00+08:00"
So without moment-timezone appears to have the behavior I described above. It should be the same behavior with moment.tz.setDefault.
Indeed, I just found this in the docs: http://momentjs.com/docs/#/manipulating/utc-offset/
... Note that once you set an offset, its fixed and won't change on its own (i.e there are no DST rules). If you want an actual timezone -- time in a particular location, like America/Los_Angeles, consider moment-timezone.
:smile:
hello,
i foun this problem too using moment-with-locales.min.js 2.21.0
var a = moment();
a.format()
// 2018-03-25T22:14:54+01:00
var b = a.startOf('day');
b.format()
// 2018-03-25T00:00:00+00:00
when using the "startOf" the timezone is set to zero.
temporary solution (force set the timezone again before startOf) :
var a = moment("2018-03-25T22:24:03+01:00");
a.format()
// 2018-03-25T22:24:03+01:00
var b = a.utcOffset(a.utcOffset()).startOf('day');
b.format()
// 2018-03-25T00:00:00+01:00
If your time zone is eg Europe/London, this is correct behaviour since DST started yesterday and the start of the day actually was still in winter time.
On Sun, 25 Mar 2018 at 23:26, seltix5 [email protected] wrote:
hello,
i foun this problem too using moment-with-locales.min.js 2.21.0
var a = moment(); a.format() // 2018-03-25T22:14:54+01:00
var b = a.startOf('day'); b.format() // 2018-03-25T00:00:00+00:00
when using the "startOf" the timezone is set to zero
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/moment/moment-timezone/issues/208#issuecomment-376004438, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHo4jqgfGkobFT2_3f22wGMgfnm1xPSks5tiAn4gaJpZM4EKxb0 .
OMG I totally forgot about that! :S you're right! thanks and sorry for the wrong post :/
Any news on that? I've been suffering from this and have no idea how to counter it..
same here
@timrwood is it possible to take a look at this one? It's a 3 year old issue that I wasn't able to workaround yet :/
Same problem here, still waiting.
I recommend everyone try upgrading to a newer version of moment-timezone. I upgraded from 0.5.21 to 0.5.33 and my issue has been resolved.
Not 100% sure my issue was the same one anyone here has been having, but I think it may be.