Split parsing+formatting to a separate library

[josevalim]

Elixir v1.8 will include timezone support, which will allow Timex to shrink a bit. As Elixir calendar support improves, we want to ideally support it by an ecosystem of focused libraries. With this in mind, I would like to propose for timex to be split into:

• Timex "core" - duration, interval, shifting
• Timex parse+format - parsing, formatting (and the tokenization backbone)

This will allow people to cherry pick the features they need and complement with what Elixir core provides.

[bitwalker]

I'm +1 on this! I will plan to make this split between now and 1.8, as a new major version, 4.0. Definitely a fan of moving to a more a la carte approach to libraries, and with much of what Timex does increasingly moving to the standard library, the monolithic approach originally followed is less of a benefit.

I think the split you've defined here is a good one, though I may split out Timex's timezone support into a separate lib as well, so that between now and 1.8 there is still coverage there, but post 1.8, that dependency can just be dropped (or implement the new behavior if needed, but I suspect tzdata will do that, and Timex can drop it as a direct dependency).

[michalmuskala]

I think there's a decision to be made about what formatting language should be used.

As far as I can see we have 3 options:

• strftime - which is widely known, but very confusing and generally hard to maintain
• "mnemonics" that Timex provides as the default formatting
• CLDR format - it's the base for the new Java datetime library, it also provides an easy way for internationalizing the formatting - all the data is already available. The downside is that the format is not that well known.

[josevalim]

@michalmuskala I would say whatever timex is doing, is what timex should continue to do in terms of backwards compatibility. Of course, there is nothing stopping a separate library from exploring another option, which is ultimately what solving this issue will enable. If parsing+formatting is out of timex, then the user can pick up any other option they prefer, including timex' itself. :)

[bitwalker]

Yeah, I think initially I'd preserve the way things are done at present (though I want to swap out my old combine lib for nimble_parsec); but I would be open to the idea of adding CLDR formatting at some future point to the split-out parsing/formatting lib, I think it may ultimately be better off as a separate lib, as I doubt there is occasion where more than one style is chosen for a given application.