Typesafe unified Date and Time package using phantom record types

Request Feedback
6

Hello @Herteby, thanks for sharing this seems like a very useful tool!

I would love to have a package with a shared DateTime type definition that packages can depend on for the same reason that having common types like avh4/elm-color is useful as a type to share across packages.

Here are some examples where I have an API that accepts either a Date or a DateTime

In my RSS generator package I define a DateOrTime type which just wraps either Posix or Date: https://package.elm-lang.org/packages/dillonkearns/elm-rss/latest/Rss#DateOrTime. Here’s an example where I use that type:

I also have an API in the elm-pages SEO code that needs an ISO 8601 formatted date. I want it to accept a Date or Posix, but I resorted to the lame solution for now of taking in a String which I type alias to Iso8601DateTime, and just expecting the user to convert it themselves. I’ve just been waiting to get a nice shared type in a community package before doing that, because I wanted to avoid having a type to represent either Date or Posix in every single package that uses that type. Here’s that API https://package.elm-lang.org/packages/dillonkearns/elm-pages/latest/Head-Seo#article.

I would much prefer to use a shared community type for these APIs, so I will definitely change it out to use the type from your package once you publish it!

Suggestion for your API

The one thing I would suggest for your API that would be helpful for my use cases is I think it would be nice to have a fromDate helper that takes in justinmimbs/date Date value, similar to the fromMillis and fromPosix functions you define here:

I know that it would introduce an extra dependency, but I think users’ code will often store their data as a Date value (when accurately models their data), and only convert it to the DateTime type defined by your package once it is passed to another API, like my RSS package or my elm-pages SEO API. Since your DateTime type is “lossy” in a way (you lose the type information that the value was originally stored as something representing only a date, not a date with a time specified), so it wouldn’t make sense for users to store it as that type in their own code.

Would love to see this published, thanks again for working on this project.

1 Like