Skip to content
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.

Sign up for GitHub

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

Jump to bottom

parseZone(s) differs from moment(s).utcOffset(s); #3520

Closed
bkapicka opened this issue Oct 22, 2016 · 4 comments
Closed

parseZone(s) differs from moment(s).utcOffset(s); #3520

bkapicka opened this issue Oct 22, 2016 · 4 comments
Labels
Bug

Comments

@bkapicka
Copy link

Description of the Issue and Steps to Reproduce:
moment.parseZone does not produce same results as mentioned in parseZone() Docs. The docs state that moment.parseZone is equivalent to parsing the string and using moment#utcOffset. This fails with /-00:00. Example below:

var test = '2016-10-20T03:00:00 00:00';
moment(test).utcOffset(test).format() // Good: 2016-10-20T03:00:00Z
moment.parseZone(test).format()       // Bad:  2016-10-19T22:00:00Z, Expected: 2016-10-20T03:00:00Z

Environment:
Node 6.6.0 on OSX

Other information

console.log( (new Date()).toString())  // Sat Oct 22 2016 09:06:24 GMT-0500 (CDT)
console.log((new Date()).toLocaleString())  // 10/22/2016, 9:06:24 AM
console.log( (new Date()).getTimezoneOffset())  // 300
console.log(moment.version)  // 2.15.1
@icambron icambron mentioned this issue Oct 23, 2016
Closed
@icambron icambron added the Bug label Oct 23, 2016
@TimHambourger
Copy link

I'm seeing the same. I've also observed discrepancies for any offset within a 15-minute range of 00:00. In those cases, moment.parseZone reinterprets the offset as hours instead of minutes.

var test = '2016-10-24T10:00:00 00:15';
moment(test).utcOffset(test).format(); // Good:  2016-10-24T10:00:00 00:15
moment.parseZone(test).format();      // Bad:     2016-10-25T00:45:00 15:00, Expected: 2016-10-24T10:00:00 00:15

I'd expect moment.parseZone(s) to behave like moment(s).utcOffset(s) in these cases too.

Environment

Chrome 53.0.2785.143 on Windows 10

Other info

new Date().toString(); //  Mon Oct 24 2016 10:12:07 GMT-0500 (Central Daylight Time)
new Date().toLocaleString(); // 10/24/2016, 10:12:22 AM
new Date().getTimezoneOffset(); // 300
moment.version // 2.15.1

@icambron
Copy link
Member

icambron commented Nov 6, 2016

We have a couple of different parseZone fixes in the works, but I'd like to keep this open and take one more pass over it to make sure we got everything; I hadn't seen the issue @TimHambourger is reporting and maybe that's still in there.

@icambron
Copy link
Member

The original issue here is fixed in 2.16.0. @TimHambourger's additional issue still happens.

@maggiepint maggiepint mentioned this issue Dec 5, 2016
Closed
@maggiepint
Copy link
Member

pr #3643

ichernev added a commit that referenced this issue Mar 2, 2017
@ichernev
Merge pull request #3643 from moment:maggie/offsetminutesashours
5c54613 
[bugfix] Fixes #3520, parseZone incorrectly handled minutes under 16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@icambron @bkapicka @maggiepint @TimHambourger