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

parseZone without timezone returning unexpected result #3083

Closed
tlrobinson opened this Issue Mar 31, 2016 · 5 comments

Comments

Projects
None yet
4 participants
@tlrobinson

tlrobinson commented Mar 31, 2016

If you provide a timestamp with no timezone offset to parseZone it seems to parse it in your browser's timezone, but then sets the _offset to 0 and _isUTC to true. This seems unexpected.

> moment.parseZone("2016-02-01T00:00:00").format()
"2016-02-01T08:00:00+00:00"

I would expect either 2016-02-01T00:00:00+00:00 or 2016-01-31T16:00:00-08:00 (assuming my browser's offset is -08:00). I think moment.utc(s).utcOffset(s) basically provides the former.

@tlrobinson

This comment has been minimized.

tlrobinson commented Apr 4, 2016

(Also moment.utc(s).utcOffset(s) doesn't work in some cases, e.x. it interprets the -DD in YYYY-MM-DD as an offset)

@icambron

This comment has been minimized.

Member

icambron commented Apr 7, 2016

Calling this a bug. Moment is getting pretty confused by there not actually being a zone there.

@icambron icambron added the Bug label Apr 7, 2016

@maggiepint

This comment has been minimized.

Member

maggiepint commented Apr 7, 2016

Does anyone have a preference for expected behavior? I looked at this one and I honestly wasn't sure what I thought it should do.

@icambron

This comment has been minimized.

Member

icambron commented Apr 7, 2016

Yeah, me neither. I'm tempted to back 2016-02-01T00:00:00+00:00 though. I think it really needs to be in a fixed-offset zone or else it's really inconsistent with the way it normally behaves. And if it is in fixed-offset mode, I think it's confusing for it to use the local offset, because otherwise the user might think it's using the local TZ. Having it return a UTC time just seems safer. I'm not sure either behavior is obvious but I think it will be easier for the user to see what's happening with the UTC default.

@ichernev

This comment has been minimized.

Contributor

ichernev commented Jun 13, 2016

So moment.parseZone should set fixed offset to 0 (if nothing else found). I guess an else clause in setOffsetToParsedOffset should do the trick.

My bad.

The offsetToString function return 0 if it fails to find a zone. So this needs to be addressed first, and then in case there is no zone just do utcOffset(0, true), so the time stays but the zone is changed to 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment