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.

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

dateFromFields with hour = 0 #17

Closed
league opened this issue Jul 8, 2016 · 2 comments
Closed

dateFromFields with hour = 0 #17

league opened this issue Jul 8, 2016 · 2 comments
Labels

Comments

@league
Copy link

league commented Jul 8, 2016

I'm getting a strange effect from dateFromFields when hour is set to 0. The doc says “Hours are input in 24 hour time range 0 to 23 valid. Returns dates in current time zone.” But watch this:

import Date.Extra.Format exposing (..)
import Date exposing (..)
import Date.Extra.Create exposing (..)
d = dateFromFields 2016 Jul 8 0 0 0 0
isoString d       -- "2016-07-08T01:00:00.000-0400" : String
hour d            -- 1 : Int

My time zone is indeed -0400:

> (new Date()).getTimezoneOffset()
240

but it's turning hour zero into hour 1. It does that all the way up the clock:

> isoString <| dateFromFields 2016 Jul 8 4 0 0 0
"2016-07-08T05:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 13 0 0 0
"2016-07-08T14:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 22 0 0 0
"2016-07-08T23:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 23 0 0 0
"2016-07-09T00:00:00.000-0400" : String

So I can provide hour 23 to get zero, but it's the next day. I also tried -1, but it clamps it to 1.

The offset issue reminds me of what's discussed in #6, but it looks like the solution there has to do with the syntax of the offset when parsing. Here I'm bypassing any parsing and trying to construct a date directly.

@rluiten
Copy link
Owner

rluiten commented Jul 8, 2016

Wow that is weird.
I ran up my notebook in timezone -03:30 - it happens to be a time zone I have got some other tests in and it exhibits the same behavior you demonstrate.
Thanks for the report.

@rluiten
Copy link
Owner

rluiten commented Jul 10, 2016

I believe I have fixed this.
I have published 7.2.1.
It was related to timezone offset of the date being created compared to the the timezone offset of epoch date (which is 1970-01-01 used internally).

@rluiten rluiten closed this as completed Jul 10, 2016
@rluiten rluiten added the bug label Apr 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants