[RFC] Timmy, a time and calendar library

Much of the work we do at Routine revolves around calendar features, and over time an internal library emerged to address some common needs in that regard. As we strive to open source most of our reusable code, I’m pleased to submit the current 0.14.2 version of Timmy for comments.

The philosophy and rationale for the library is explained at length in its root module documentation, so I will only sum up here that our design goals and possible differentiator are a high level interface, type safety, timezone safety, DST support and advanced calendar features.

We’d be happy to collect feedback on the current API and usefulness of the library before committing to a stable API.



Where does Schematic come from?

I’ll say it’s not immediately clear to me how one would construct date time in a different time zone that is not the local time zone.

This is another internal library we use to extract metadata (a schema) on type, and that can then serialize any value of that type to/from JSON, Javascript, sexp, etc. as well as produce its JSON schema, typescript type declaration, … We plan to open source it as soon as possible too, but it’s a bit early to commit to an API yet. We use it for instance to automatically exchange our objects with our rest API or convert them to/from js for the web frontend.

Timmy’s support for it is optional and it will compile without it, but odoc crashes while generating the documentation without it.

The Timezone.of_implementation lets you compute the offset however you want at any point in time, but that is indeed left as an exercise for the developer except for the system local timezone provided in Clock.timezone_local. We do not (unlike Timere I suppose) bundle timezone data inside the library.

Right okay, fair enough.

We had the same/similar design at some point for a predecessor of Timedesc, but I found that to be very difficult to use in practice (where would one source an implementation to begin with), and so Timedesc has everything bundled. But if that works for Routine then the design is very fair.

Indeed, the library is more centered around the user’s local time for now. I can only imagine the struggles to implement this, so for us it’s not worth the complexity for now – kudos for pulling it out.

I also feel compelled to mention that I realize this is probably quite redundant with your work on Timere; as we discussed personally some time ago the two efforts started roughly, I believe, around the same time.

Indeed - saw post about Routine shortly after wrapping up on Timere : D

I’m still going through the codebase of Timmy here and there - mostly interested in seeing what Timedesc (the calendar lib part of Timere) might be missing/differ.