Conversion functions to standards Date and Time ?

[Vincent Billey]

Hello,

I've been using your lib (and thank you for doing it by the way) and I think it's missing some helpers to deal with other libs.

For instance, I use rluiten/elm-date-extra to handle some light translations. I also use this lib that we made in my company elm-time-overlap.

Both (and others) use standard elm Date and/or Time types. It would be quite pleasant to have some functions to and from with your Date and DateTime. Or I am missing something?

These are not particularly complicated and I would gladly make a PR with them if you want. I don't know if they would fit in their modules or inside another Util module though.

As I see things, I would love for :

Time.Date.fromDate : Date.Date -> Time.Date.Date
Time.Date.toDate : Time.Date.Date -> Date.Date
Time.Date.toTime : Time.Date.Date -> Time.Time
Time.Date.toWeekday : Time.Date.Weekday -> Date.Day
Time.Date.toMonth : Int -> Date.Month

Time.DateTime.fromDate : Date.Date -> Time.DateTime.DateTime

The last one is debatable because you could just use Date.toTime |> Time.DateTime.fromTimestamp but it could just be that.

What do you think?

[Eric Gjertsen]

I think the point of this library is to replace the core Date and Time types entirely, that may be why conversions are not provided.

However, in my experience you do need to go through the core types in one obvious place: to get the current local date and the local date from a timestamp. So I have some helper functions like:

import Date as CoreDate
import Time as CoreTime
import Time.Date as Date

-- javascript  `new Date(Date.now())`
currentDate : Task x Date
currentDate  = CoreDate.now |> Task.map coreDateToDate

-- javascript  `new Date(ts)`
localDateFromTimestamp : CoreTime.Time -> Date
localDateFromTimestamp ts = CoreDate.fromTime ts |> coreDateToDate

[Vincent Billey]

There is some other places though. Translations would be one thing, there is libraries that allows conversion between a Month to the localized version, same for the DayOfWeek.

I don't think this library needs to do all date things and I pointed to other libs in my first message.

That being said, the conversions are really simple to do and I did them for my needs. I just supposed it would be simpler to have them directly in the lib, that could also allow some structural change without forcing users to rewrite their conversion functions. As you wish :)

[John Soo]

I used the timestamp functions with minimal overhead. Since the core functions use the javascript date directly, it makes sense to break from core in this library. That said, would anyone mind if this issue were closed?

[Vincent Billey]

As the original poster, I'll just close it. Time has passed :)