Using a default timezone breaks clone() and startOf() functionality with explicit zones

[reinhrst]

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.

[mattjohnsonpint]

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"

[mattjohnsonpint]

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.

[mattjohnsonpint]

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.

😄

[seltix5]

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

[reinhrst]

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 ***@***.***> 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 <#208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHo4jqgfGkobFT2_3f22wGMgfnm1xPSks5tiAn4gaJpZM4EKxb0> .

[seltix5]

OMG I totally forgot about that! :S you're right! thanks and sorry for the wrong post :/

[SudoPlz]

Any news on that? I've been suffering from this and have no idea how to counter it..

[F-Moody]

same here

[SudoPlz]

@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 :/

[djereg]

Same problem here, still waiting.

[dtgay]

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.