moment-timezone
moment-timezone copied to clipboard
Incorrect date when manipulating time around DST change
Moments initialised with a timezone don't seem to behave correctly when manipulating the time.
My machine timezone is Europe/London.
moment.tz.guess()
// "Europe/London"
moment.tz('2018-03-25T00:00:00', 'Europe/London').hours(1).format()
moment.tz('2018-03-25T00:00:00', 'Europe/London').set({hours: 1}).format()
// "2018-03-25T00:00:00Z" - Incorrect
moment('2018-03-25T00:00:00').hours(1).format()
moment('2018-03-25T00:00:00').set({hours: 1}).format()
// "2018-03-25T02:00:00+01:00" - Correct
Hey sorry to bump this but it is affecting us in production, can you confirm whether we are doing something wrong or if this is a bug. Thanks Alex.
Appreciate you are busy, but if you a have a free moment it would really help us if you could let us know if this is a moment-timezone issue. Thanks.
@mj1856 @timrwood Is this package still maintained? Issues seem to be piling up with no replies, should we look at moving to luxon?
Sorry for the delayed response. Yes, this project is still being maintained, but I'm in dire need of additional maintainers. Anyone wanting to step up to the plate should DM me on twitter @mj1856.
Note that Tim has stepped down permanently.
Regarding the issue you reported, since the 1:00 hour is invalid (doesn't occur on that day in that time zone), the result of the setter should honor the moment.tz.moveInvalidFoward setting (which is true by default). Indeed this happens when passing the invalid value in during construction, but it appears the setters aren't taking this into account - so it is moving backward an hour instead.
To clarify:
moment.tz.moveInvalidForward
//=> true (the default)
moment.tz('2018-03-25T01:00:00', 'Europe/London').format()
//=> "2018-03-25T02:00:00+01:00" (correct)
moment.tz('2018-03-25T00:00:00', 'Europe/London').hours(1).format()
//=> "2018-03-25T00:00:00Z" (incorrect)
@mj1856 I'm not sure where to start with this I can't immediately see any code relating to setters.
@mj1856 Sorry to bump again we really need to get this resolved, I imagine quite a lot people are hitting this in production and not noticing.
A workaround is quite difficult also.
@AlexMeah I'll start to debug & fix this, hope that I'l provide a fix soon