Supporting them in Date struct will add so much complexity. the only two ways are either changing Date structure or Hacking other calendars in it.
One complexity i can think of is the presentation. how would as a developer present a Date that has more than 3 factors. using Date will become tricky. Date should be represented as a format for calendars which follow year, month, day rules. as i said, it is more convenient for them to have their own structs. I think we should not handle them in Elixir native Date struct.
And i have to say i’m still not happy with overheads and complexity added to Elixir to achieve calendar conversions using JD/RD. although that seems to be only my concern in this trade-off.
I do not think Elixir’s standard library will become more complex because of this change. Rather, it will be a simple and well-defined base that libraries implementing the different calendars can build on, and allow them to be interoptable. This was the whole reason for Calendar, Date, Time, DateTime and NaiveDateTime to be added to Elixir in the first place.
@josevalim@kip: I’ll create a simple library that implements some of the calendars described in the Calendrical Calculations and Calendrical Calculations II papers while attempting to use Elixir’s existing Calendar, Date, DateTime etc. structs, and see what issues arise.
I didn’t mean the ability to convert calendars made it complex. the strict usage of JD/RD made it complex. even in Go and .NET where they use JD/RD, they use it is inside the Calendars implementation and they can choose either to use Integer date or any other formats they want. (In .NET the base timestamp is ISO DateTime which everyone knows about and there are many different algorithms for conversion from/to it)
But i agree JD/RD it is a good approach and does not have many downsides of other timestamps and of course it is simple.
But changing or making Date struct Dynamic will make very larger complexities especially in integrations of Elixir and other APIs. don’t you think?
Right now, Elixir does not work with Julian Day or Rata Die yet; this topic is the discussion about adding it.
Using JD/RD and converting to and from it results in algorithms that are considerably less complex than when UTC is used as intermediate format. Furthermore, as @kip has noted, there exist implementations of conversions from and to JD/RD for at least 23 existing calendars.
The idea is to hide this internal representation and conversion from the end users. Only people that implement new calendars have to know about it.
I would see downside to having made the Date, Time, DateTime etc. structs dynamic, as the internal representation could still have been pattern-matched on if required. However, as these structs now have become part of the core language in their current form, they should not be altered as this would be a backwards-incompatible change. So no: they will not and should not become dynamic.
I could see an :extra field being useful for Date, Time, DateTime etc. to allow calendar implementations to store information that is not part of the normal fields. This makes more sense to me than e.g. the ISO Week Date calendar using :month to store the week number.
I really like the combination of {RD, microseconds} format. and i think @kip is implementing it.
The only concern i have is about developers who is going to implement another calendar for Elixir. if their algorithm does not work with JD they should change it. JD is really good, i can’t think of a situation that it will fail. but it would be a good idea if Elixir could give developers freedom to choose either to follow this rule or not.
Sure, using :month as week number is not a good hack. it may work for some people but surely it is not going to be used officially. :extra field may be a good idea. I also think another third-party implementation of Date would be a good idea for those scenarios.
@alisinabh: @kip is working on a Pull Request right now that uses Rata Die as internal representation. The current version uses integers, but he is planning on writing a version using either the millisecond format or a fractional format. This was stated by him a few posts ago.
As previously stated, I strongly advise the use of a fractional format as a millisecond representation is:
imprecise.
decoupled from the length of one earth rotation and therefore suffers from leap seconds.
I am also very interested about the opinion of @Lau, as he is the author of the original Calendar library that the structs that are now part of Elixir Core got split off from.
@OvermindDL1 Oh, sorry to hear that, i hope you get better soon
This is a pretty good idea. It is beautiful but unfortunately i don’t think it is currently achievable due to its non-backward compatible nature without getting our hands dirty.
And not to mention, the year, month, day structure will handle 99.9% of use cases. So, not supporting it in core data structures would not be a big deal! I personally don’t know any languages that does support this. even Joda-Time is strict about year, month, day structure in BaseDateTimes. although you can implement your own version of a DateTime and use Joda calendars (Chronologies).
