cdegroot
Should Calendar types and timezones be part of Elixir standard library?
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 )
Most Liked
josevalim
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.
dimitarvp
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.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"