good_times

good_times copied to clipboard

Let's use as much as we can from the Calendar module.

We should

• accept Calendar structs as input.
• struct in means same kind of struct out.
• if possible, re-use types from Calendar.

(On the last point about the type declarations. Calendar has looser types than GoodTimes. Maybe there's some benefit in tightening them, but ours are actually too tight. A leap-second is second 60, so the correct range would be 0..60. I'd open that as a separate issue, but why bother.) :)

I suggest starting with backwards-compatible changes (minor version change), and at a future point, when Calendar has been released and has serious uptake, release a major version where Calendar is the default. I want us to support a common data structure for dates and times across the Elixir ecosystem.

Question is, how do we handle the functions relative to now? They aren't called with enough information to pick an appropriate return value. Should they accept a keyword-list option return: :struct? And later, when the default changes, return: :tuple? Or should we supply functions with different names? now_tuple, now_struct. Or should we supply a different module? GoodTimes.Calendar.now?

I think different modules is probably the best way to go. We could move all our existing stuff into GoodTimes.Erlang and delegate or simply call the functions in the main module. Then put all the functions for Calendar structs in GoodTimes.Calendar. That way, if someone wants to use GoodTimes with Calendar structs immediately, they can alias GoodTimes.Calendar, as: GoodTimes and call GoodTimes.a_second_ago to their heart's content. It would also make it easy for a library user to fix the breaking change later on, by simply alias GoodTimes.Erlang, as: GoodTimes.

If we go with different modules, we should formalize the fact that they have such similar APIs with either a behaviour or a protocol. A protocol seems doable, as we rely on a few base functions relating to seconds, days and months.

WDYT?

As an alternative to expanding GoodTimes, we could also build a new library on top of the Elixir 1.3 Calendar types (BetterTimes as a name for that lib comes to mind). The upside of doing so is that we could ignore backwards compatibility until we want to merge the two libraries or, keeping them separate, add additional conversion functions.

Another reason for spinning up a new lib is that we can drop unused features (if there are any). We kind of threw in the kitchen sink when building GoodTimes and we could probably stick to a subset of the functionality.

If we want to start out really small, we could just add a few conversion functions for converting Erlang-style datetime tuples to Elixir Calendar types and vice versa. However, that approach will not make the library user's code very nice as they'd have to keep in mind to convert values back and forth.

I'm inclined to initially keep GoodTimes and BetterTimes separate. WDYT?

At any rate, we should add conversion functions for Calendar.{Date, Time, NaiveDateTime, DateTime} <-> tuple-style formats.