Given a JsonDateTime record like you show, you can use the Date.Extra
function fromSpec to create a date with any time zone offset.
import Date exposing (Date)
import Date.Extra as Date
import Date.Extra.Facts exposing (monthFromMonthNumber)
dateFromRecord : JsonDateTime -> Date
dateFromRecord { year, month, day, hour, minute, second, millisecond,
timezone } =
Date.fromSpec
(Date.offset <| timezone.offset_utc + timezone.offset_std)
(Date.atTime hour minute second millisecond)
(Date.calendarDate year (monthFromMonthNumber month) day)
For example:
dateRecord : JsonDateTime
dateRecord =
{ year = 2016
, timezone =
{ until = "max"
, offset_utc = -360
, offset_std = 60
, full_name = "America/Chicago"
, from = "min"
, abbreviation = "CDT"
}
, second = 8
, month = 7
, minute = 14
, millisecond = 86
, hour = 4
, day = 18
, calendar = "gregorian"
}
Date.toUtcIsoString (dateFromRecord dateRecord)
-- "2016-07-18T09:14:08.086Z"
Is this what you're looking to do?
Thanks,
Justin
On Wednesday, July 20, 2016 at 10:35:15 AM UTC-4, OvermindDL1 wrote:
>
> Just started using the Date.Extra modules yesterday. The main thing I
> wish that Date (either in Elm or in Date.Extra) had was a constructor that
> could take a javascript-style date-record and convert it to an Elm Date.
> Specifically I am used to being giving this JSON (from a remote server) to
> a Javascript Date object and the Date object just does 'the right thing',
> timezone and all correctly:
> ```json
> -- The Elm record I convert it to:
> type alias JsonDateTime =
> { year : Int
> , timezone :
> { until : String
> , offset_utc : Int
> , offset_std : Int
> , full_name : String
> , from : String
> , abbreviation : String
> }
> , second : Int
> , month : Int
> , minute : Int
> , millisecond : Int
> , hour : Int
> , day : Int
> , calendar : String
> }
>
> -- A logged record from Elm with data:
> { year = 2016
> , timezone =
> { until = "max"
> , offset_utc = 0
> , offset_std = 0
> , full_name = "UTC"
> , from = "min"
> , abbreviation = "UTC"
> }
> , second = 8
> , month = 7
> , minute = 14
> , millisecond = 86
> , hour = 4
> , day = 18
> , calendar = "gregorian"
> }
> ```
> I am doing a very naive conversion right now that that ignores the
> timezone and stores it as UTC, regardless of what it may be (thankfully
> 'this' server sends in UTC, but not all I connect to do)...
>
> On Tuesday, July 19, 2016 at 9:30:48 PM UTC-6, Justin Mimbs wrote:
>>
>> Thanks, Aaron! I appreciate the feedback.
>>
>> I published version 2 of the package; all functions that work directly
>> with the Date type are now in a single module, Date.Extra.
>>
>> Thanks again,
>>
>> Justin
>>
>>
>> On Saturday, July 16, 2016 at 11:29:33 AM UTC-4, Aaron VonderHaar wrote:
>>>
>>> In general, I believe the best approach is to have a module roughly
>>> correspond to a data type, and to have both the type definition and all the
>>> relevant functions in that single module.
>>>
>>> In your case, Date is already defined in elm-lang/core, but I do think
>>> it would be better to have all the extra functions in a single module (or
>>> at least all the things that a normal user of your package might want to
>>> use). It's better both for the reason you mentioned (to avoid having to
>>> import a bunch of modules just to work with Dates), and also to avoid users
>>> of your package having to remember what is in each of the submodules.
>>>
>>> My only other suggestion would be to check in with rluiten and/or
>>> elm-community and see if there's any possibility of combining the existing
>>> elm-date-extra packages into a single package.
>>>
>>> Best,
>>> --Aaron V.
>>>
>>>
>>>
>>> On Sat, Jul 16, 2016 at 7:30 AM, Justin Mimbs <justin...@gmail.com>
>>> wrote:
>>>
>>>> Hello Elm Discuss,
>>>>
>>>> I published an elm-date-extra
>>>> <http://package.elm-lang.org/packages/justinmimbs/elm-date-extra/1.0.1>
>>>> package last week, where around 50 things are organized into 5 modules.
>>>>
>>>> Date.Convert - convert dates to other types (mainly formatted strings)
>>>> Date.Create - create dates from other types
>>>> Date.Extract - additional extractions to those in the core library
>>>> Date.Facts - lookups and constants
>>>> Date.Math - operations for dates (e.g. floor, add, clamp, range)
>>>>
>>>>
>>>> So far when I use the library, I find I'm usually importing at least 3
>>>> of its modules, and aliasing them all as `Date`. This has given me the
>>>> feeling that the library might be easier to use if it just exported
>>>> everything from a single Date.Extra module. Do you think this library
>>>> benefits from being split up, or would it be nicer in a single module?
>>>>
>>>> I'd be interested in any other suggestions on the API as well. If I'm
>>>> to make breaking changes by reorganizing the package, I'd be happy to
>>>> include other changes at the same time.
>>>>
>>>> Thanks!
>>>>
>>>> Justin
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Elm Discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to elm-discuss...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
