I believe there is not. however, adding an :extra field to Date, DateTime and NaiveDateTime would be useful to make these existing types more suitable for storing information from other calendars.
As was mentioned in this topic in more detail earlier, a simple intermediate representation such as Rata Die:
makes conversions simpler; other calendars do not need to care about the Gregorian’s leap rules.
makes conversions between two non-ISO8601 calendars work for datetimestamps more than 6 months in the future, as no leap second information is needed.
Going back into this, doesn’t it mean that, when encoding a given datetime to the tuple format, I would need to know if that particular day has leap seconds or not, since the presence of leap seconds changes how we will encode the seconds in a day into the whole fraction?
I thought earlier that it would be possible to ‘just pick a high enough denominator’ and then use this (implicit!) denominator for all conversion calculations, which would be precise enough.
Besides this being a bad idea because it is a weird, implicitly-defined constant, I found out that even when using a Superiour Highly Composite Number as fixed denominator, there would be many instances in which a loss of precision would occur. I’ll elaborate on these experiments if you want.
So, I made a very small proof-of-concept (using a map instead of a tuple for clarity) on GitHub that uses a {day, numerator, denominator} format.
When talking to @kip about this yesterday, he came with the very astute observation that it might very well be simplified to ‘just’ using a float: {integer_days, float_last_day_fraction}. While floats have a rounding error, the 16 decimals of guaranteed matissa precision are enough to work with times in sub-microsecond format.
I believe he is currently using this approach in his being-reworked Pull Request.
So, to address your question directly:
Only if the to-be-encoded datetime is in UTC, i.e. Calendar.ISOor erlang-time-tuple format.
And then only if the to-be-encoded datetime is June 30th or December 31th.
If there should be a leap second in the current UTC day and we do not know about it (because, for instance, it is a date in the far future), we might be off by (86401 / 86400) - 1 = 0.000011574074074 seconds ≈ 11 microsecondsfor that particular date only. Any time lower than 23:59:60 will have even less error.
Ok, that was going to be my follow up point. It seems when encoding times between different calendars we would lose precision anyway because the days are slightly longer or shorter. So the “leap seconds base” is only useful when encoding in the same calendar. But, if it is the same calendar, we don’t need to encode the time.
Perfect. This clarifies it. So would it make sense to rather add two functions to the Calendar behaviour? One that converts a Date to integer and another that converts the Time to a fraction? There is no need to convert the time if you are interested only on the date. /cc @kip
Almost. There is however, one important caveat to note: Some calendars start the next day at sunrise, some at noon, some at sunset and some at midnight. This means that conversion from one date to another might not be unambiguous, as a date in Calendar A might overlap with two dates of Calendar B.
Thus, I think that the date_to_rata_die should return an integer as well as a fraction.
I am not entirely sure yet how date (without time) conversion could be handled gracefully; we might want to return a list of possibilities. An alternate approach could be to restrict date (without time) conversions to calendars that have the same day-rollover point; meaning that if a developer wants to convert to another, he has to make a choice as for what time-of-day is used. This is similar to how NaiveDateTime is restricted w.r.t DateTime.
@callback Calendar.time_to_day_fraction(Time.t, options) :: float. Returns a time divided by the total fraction of day. options is a keyword list that might be used to specify day properties that are not stored in the Time struct itself. (such as: should we treat the time as a time on a leap day).
@callback Calendar.day_beginning_relative_to_midnight() :: float, returns 0.0 if the day rolls over begins at midnight, 0.25 if the day rolls over at sunrise, 0.5 if at noon, etc.
About the calendar functions, I will leave it up to @kip, but note the Calendar functions should not receive structs. Otherwise we have cyclic dependencies between those which, although they are fine in Elixir, it is usually not a good practice.
@josevalim another thing that caught my eye was there are callbacks like Calendar.date_to_string/3 and Calendar.datetime_to_string/11. Why there is no callbacks to get date from string? I mean, what to do to parse a string to a calendar implementation?
Most of the questions to why Calendar in Elixir does not do something is likely because there was not a discussion about including such features. We could discuss parsing but that would be a separate discussion.
@josevalim, @qqwy, sorry for being a bit quiet last 24 hours, a few other things got in the way but I’ve been following and on board with the discussion. Will be done in a couple of days after I update some tests around the leap second boundaries.
Yes, my current version is {days_since_epoch, float_fraction_of_day} as a tuple, not struct, in order to keep it simple and follow José’s advice.
I will have an updated PR for review in a couple of days that lev
It seems when encoding times between different calendars we would lose precision anyway because the days are slightly longer or shorter. So the “leap seconds base” is only useful when encoding in the same calendar. But, if it is the same calendar, we don’t need to encode the time. 
