-
Notifications
You must be signed in to change notification settings - Fork 36
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
Format date seems to use incorrect offset #6
Comments
Hi, that's an interesting failure. In the mean time what is the timezone of your javascript vm ? I would like the result of the following two commands please. I hope to look at this further tonight after work. |
|
I added a copy of your test into my tests. I created import Date.Extra.Format as Format
dateToISO = Format.utcIsoString Its not failing for me... What is your dateToISO function could it be the problem ? I added your test into the test suite, and its part of version 4.0.0 which was created to shift names spaces. |
oops! module Util.Extra (..) where
import String
import Date exposing (Date)
import Date.Format as Format exposing (format, formatUtc, isoMsecOffsetFormat)
import Date.Config.Config_en_au exposing (config)
dateToISO : Date -> String
dateToISO date =
formatUtc config isoMsecOffsetFormat date |
Ok, yours works though it does not output this format "2016-03-22T17:30:00.000Z". It outputs "2016-03-22T17:30:00.000+0000", however I do not see the 18 hour value. Can you try I am still curious where that 18 is coming from. |
Ahh yes, when constructing the test I didn't even look at the way the offset was formatted. Either way, the 18 is indeed odd. The test still fails: test
"output is exactly the same as iso input"
(assertEqual
(Ok "2016-03-22T17:30:00.000+0000")
(Date.fromString "2016-03-22T17:30:00.000Z" `Result.andThen` (Ok << dateToISO))
)
|
This also fails: , test
"output is exactly the same as iso input"
(assertEqual
(Ok "2016-03-22T17:30:00.000Z")
(Date.fromString "2016-03-22T17:30:00.000Z" `Result.andThen` (Ok << Format.utcIsoString))
)
|
I would focus on the hour discrepancy first if i saw it to, i don't think id notice the time zone difference at end of string either. I am trying to think of something else (anything else) that might cause that hour difference. Time to grasp at straws... (asking for any thing that might vaguely matter) What javascript engine is running the code is it a browser which ? is it node version ? Is it possible to share a project or maybe an extracted piece of your project in isolation to let me try and get a sclose to your soruce base as possible ? |
I can screen share |
I am at work at the moment, cant do anything till tonight at least 9 hours away. |
…hmark test(convertingDates): adjusted still no closer to resolving issue #6
Hi, I am still intereted in the result of the following in your javascript environment. |
Hey! I think the problem is that Date.Extra.Create's The JavaScript spec for Running in Node, PST obvs
|
Now that is a interesting observation, not one I had considered till now. I have memories of trying to detect the current (as in relation to the date and time we are working with) timezone offset to compensate, but I could have made a mistake or just did something wrong. I get the offset by derivation so it might have a bug or it might not be easy to fix. I have no way to just ask for it from the underlying javascript vm at the moment. |
I have just released 5.0.0 quite a lot of work around improving handling of timezone offsets particularly negative offsets and transitions to and from daylight saving. As well as better handling of daylight saving in date math. I believe I fixed two areas that may be related to the behaviour you observed @joeandaverde so its probably worth checking. Thankyou @tesk9 for suggesting daylight saving offsets were a candidate area for examination it was a deep rabbit hole :) |
Here's a test that fails for me. I'm currently in CDT.
The output is
2016-03-22T18:30:00.000Z
instead of2016-03-22T17:30:00.000Z
.The text was updated successfully, but these errors were encountered: