What’s the reason to include this in core? One of the things I like about Elixir’s standard library is its small surface area. It keeps it nimble, simple to understand, and usually I use pretty much all of it in any project.
That will not hold up for the endless headache that human calendar systemsand timezones represent. Very often, I don’t need it (and even if I do, I don’t want it but that’s a different topic ). There are excellent libraries out there for when people do need it, but given that that is often not the case (I just went through our projects and the vast majority doesn’t pull in timex) it’s fine to have it in a library.
Personally, I put timezones (and all the other calendaring support) in the same bucket as money types, currencies, fixed decimal calculations, matrices, etcetera: very useful to have libraries for, but given the relatively limited scope, I would not add it to the core.
(Please, please, please don’t make the mistake of defining the success of Elixir by an ever expanding scope and larger codebase )
If I read this correctly, the core team wants good standardized contracts for dealing with times, dates and timezones. What would only change is that libraries like timex, calendar and ecto will be modified to implement behaviours which will be defined in the Elixir stdlib itself; they will still be separate libraries, only they will all implement the now standardized contracts. The implementation freedom – and pluggability – remains.
My point is: calendars are very domain specific and I think they don’t belong in core. If a standard contract is needed, I’m sure that the three sets of library maintainers can work one out.
One of the articles in there was written by @Lau, which maintains the calendar library and participated in the design of the Calendar types in Elixir.
Calendar types are already part of Elixir. The reason that most of your projects most likely don’t pull in timex is exactly because of those types. Before we had builtin support for those, most projects resorted to either passing tuples around, such as {{year, month, day}, {hour, minute, second}}, or we created ad-hoc types.
This is not a discussion if we should add Calendar types or a timezone contract to Elixir. This discussion happened 2 years ago. This is about the best way to finish the last bit.
No, it’s because I don’t need times and dates - a lot of projects don’t need them period, and in the others, I have a very strong preference to stay with epoch seconds for as much as possible and only in the presentation layer (these days, typically a JS SPA) switch to “human units”.
Anyway, apparently that decision has been made so I’ll shuddup now. Two years ago, I would have argued that the time and date types should be removed from the core, still my opinion, but I guess I arrived too late at this particular party
The thing is Phoenix can be the presentation layer. Phoenix is a full-featured framework, including (in traditional sense) the frontend. Not every website has to be overengineered into a distributed system by building a SPA.
Anyway, I think Time and Date datatypes in Elixir are mostly encountered when working with Ecto and Postgres, not on the frontend side of things. So you can see it’s a more universal data type.
I think it wouldn’t hurt it they were in a separate library but this way we have less fragmentation. And only the basic datatypes are included, libraries are still useful for extending calendar and timezones functionality.
When it comes to the Call for proposals, it does not say we should include all functionality in the standard library, but that we should support timezones with these datatypes in a standardized fashion. Libraries will still be often useful for using these datatypes. See:
). There are excellent libraries out there for when people do need it, but given that that is often not the case (I just went through our projects and the vast majority doesn’t pull in 
