Format date seems to use incorrect offset about elm-date-extra HOT 14 CLOSED

Hey! I think the problem is that Date.Extra.Create's getTimezoneOffset doesn't incorporate Daylight Savings Time.

The JavaScript spec for getTimezoneOffset explicitly covers daylight savings--it's part of how local time is calculated.

Running in Node, PST obvs

> (new Date(2016, 1)).getTimezoneOffset()
480
> (new Date(2016, 4)).getTimezoneOffset()
420

from elm-date-extra.

Hi, that's an interesting failure.

In the mean time what is the timezone of your javascript vm ?
I don't know if it is related but it might be.

I would like the result of the following two commands please.
new Date()
and
(new Date()).getTimezoneOffset()

I hope to look at this further tonight after work.

from elm-date-extra.

new Date()
Tue Apr 12 2016 17:21:58 GMT-0500 (CDT)
(new Date()).getTimezoneOffset()
300

from elm-date-extra.

I added a copy of your test into my tests.

I created dateToISO as follows.

import Date.Extra.Format as Format

dateToISO = Format.utcIsoString

Its not failing for me...
Scratching my head at the moment.

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.

from elm-date-extra.

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

from elm-date-extra.

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 dateToISO = Format.utcIsoString as i mentioned above.

I am still curious where that 18 is coming from.

from elm-date-extra.

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))
        )

from elm-date-extra.

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))
        )

from elm-date-extra.

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 ?
What platform are you on windows/osx/linux ?
What do these return in your javascript environment ?
(new Date("2016-03-22T17:30:00.000Z"))
(new Date("2016-03-22T17:30:00.000Z")).getHours()

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 ?

from elm-date-extra.

I can screen share

from elm-date-extra.

I am at work at the moment, cant do anything till tonight at least 9 hours away.

from elm-date-extra.

Hi, I am still intereted in the result of the following in your javascript environment.
(new Date("2016-03-22T17:30:00.000Z"))
(new Date("2016-03-22T17:30:00.000Z")).getHours()

from elm-date-extra.

Now that is a interesting observation, not one I had considered till now.
I will have a look at it on the weekend,

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.

from elm-date-extra.

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 :)

from elm-date-extra.