How to be with DateTimeData alias being internal?

[Fedor Nezhivoi]

Hello!

Currently documentation for DateTime.zero mention record updates for the DateTimeData.

This is a bit weird since DateTimeData is not part of a public interface. So to figure out what you can update there, you need to check source code for it. By reading the code I assume you want to keep it internal.

What about removing DateTime.dateTime function and making DateTime.zero return DateTime? This way nothing gets exposed and the previous behavior is still possible with functions like setYear or setMonth.

Examples from the readme will then change like this:

-- OLD
dateTime { zero | year = 2016 }

-- NEW
zero |> setYear 2016

I think that this will follow Elm idea of "one way to do thing" (now you can actually use both ways) pretty nicely. Also with current compiler behavior it is inconvenient to use DateTime.zero if you use qualified imports - { DateTime.zero | year = 2016 } won't work.

Would be happy to make a PR with the change if it makes sense.

What do you think?

[Scott Smith]

@gyzerok thanks for your idea; I see what you're explaining and it makes sense. I like your change; technically it's clearly better. But what you want to change is the API for THE convenience method for generating all of the elm-time objects. Inconvenient for existing users to have to change.

Are you available to discuss on Slack? I'd like to discuss this; can we do this without immediately changing the API? If you're available

[Scott Smith]

I just pushed the major pre-elm 0.19 changes; elm-time is now at version 3.0.3.

I am presently somewhat discouraged at the entire elm-time API; it is so inconsistent, and, I think for no really good reason except that it just takes time for the "right" API to reveal itself.

Anyways, onward to converting to Elm 0.19.

[Scott Smith]

Per discussion on Slack, @gyzerok and I both agree that fixing the API is going to be harder than anticipated. Closing this while a broader solution is identified.