parseZone without timezone returning unexpected result

[tlrobinson]

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]

(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]

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

[maggiepint]

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]

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]

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.