Looking for feedback on a Date extra library

[Justin Mimbs]

Hello Elm Discuss,

I published an elm-date-extra 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

[Aaron VonderHaar]

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.

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

[Justin Mimbs]

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

[OvermindDL1]

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

[Justin Mimbs]

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

[OvermindDL1]

Hmm, that looks exactly right, fascinating, I'd not noticed that function in the docs.  Awesome.  :-)

[OvermindDL1]

Apparently the `elm-date-extra` package I had was not this one but rather:

```json

"rluiten/elm-date-extra": "7.2.1 <= v < 7.3.0",

```

And I am using it for some functions that don't exist elsewhere (mostly relative dates).  Would there be any issues having both installed?  Initial tests show they are they working together.