It is option B. If we don't delegate to the calendar implementation, we always hardcode to Calendar.ISO. This way users of other calendars get a hard failure and we can discuss how to best move forward. So if you look at the "to_erl" implementation, you will see that it only supports Calendar.ISO.
This means it is time to have the conversation. :) We have two options: 1. Make "to_erl" part of the calendar behaviour. However, since the Erlang representation is a Proleptic Gregorian calendar, to_erl would effectively be a conversion to gregorian. 2. Make date_compare and naive_date_time_compare part of the calendar behaviour. One question you may know the answer: are calendar conversions bijective? For example, is a date in one calendar guaranteed to represent a single date in another calendar and vice-versa? I would think that yes, because of time, but never underestimate calendars. But if yes, we could convert dates to a known calendar (Proleptic Gregorian) and then compare them (solution 1). This would also allow comparisons between calendars (which again, requires them to be bijective). -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J_wV%3DtzXdjUubrYpi_fgPOSa39eG0CAwa0y3F3oMvGGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
