I have discovered that I managed to copy concepts from NodaTimes Period concept to Duration and there Duration concept to Period I got it backwards. Which I am sure is not helping anyone with back ground in nodatime doing the right thing with elm-date-extra.
An Elm language package for working with dates and times. See bottom of this document for important history notes.
This project uses elm-format for formatting.
import Date.Extra.Config.Config_en_au exposing (config) import Date.Extra.Format as Format exposing (format, formatUtc, isoMsecOffsetFormat) displayString1 = Result.withDefault "Failed to get a date." <| Result.map (format config config.format.dateTime) (Date.fromString "2015-06-01 12:45:14.211Z") displayString2 = Result.withDefault "Failed to get a date." <| Result.map (formatUtc config isoMsecOffsetFormat) (Date.fromString "2015-06-01 12:45:14.211Z")
Please be warned that there are many ways to manipulate dates that produce basically incorrect results. This library does not yet have much in the way of prevention of doing the wrong thing. Dates, times, timezones and offsets can make working with dates a challenge. This library is quite new and even though it has tests and written in Elm it might eat your lunch if you are not careful.
It is hoped that with feedback from users and reviewers with deep Type-zen it will be possible to improve the API to reduce the chances of doing the wrong thing with out realising it.
I think there may be value in creating Types for each type of date. Types as covered in the Noda Time documentation such as
This library has a simple Period and Duration modules at the moment, I hope this is a step in the right direction and does not muddy the water.
In the long run this may require writing a date parser and introducing Elm native time zone structures in.
Many ideas and concepts shamelessly borrowed from the following.
This uses elm-test for testing so install it if you dont have it.
Only major (and recent) changes are listed here.