I think a good approach would be to define a reference date, from which all
calendars can use as a point to convert to and from. This method is used in
the book Calendrical Calculations, and their associated Java/Scheme
implementation called Calendrica (which includes Egyptian/Armenian,
Gregorian, Julian, Coptic/Ethiopic, ISO, Islamic, Hebrew, Ecclesiastical,
Hindu, Mayan, Balinese Pawukon, Persian, French Revolutionary, and Chinese
calendars). It works by defining a "fixed" calendar, which starts with day
1, and then defining conversions to and from the "fixed" calendar by using
the number of days relative to that calendar. In Calendrica, the start of
"fixed" date 1 is the same as the start of the Gregorian (proleptic)
calendar, e.g. midnight of January 1st, year 1, thus to_fixed({1,1,1}) ==
1. Since the passage of time can be represented as days -1, 0, 1, 2, ..N
relative to the fixed calendar, this provides a way to convert between any
set of calendars, by simply converting to the fixed calendar, and then
converting to the destination calendar. Time is similarly treated, as each
calendar also defines the point in time at which a day "starts", so
conversions are all unified to occur at noon. Since in many calendars this
is based on location, it is up to the calendar implementation to convert to
noon prior to doing conversions to another calendar. There is a great deal
more that goes into it, but hopefully it at least sparks some discussion
about how to approach this. In my opinion, it's the best approach I've come
across so far (and I wouldn't be surprised if it's effectively the only
workable approach).Paul On Mon, Dec 19, 2016 at 4:32 PM, José Valim <[email protected] > wrote: > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J_wV%3DtzXdjUubrYpi_fgPOSa39eG0CAwa0y3F3oMvGGw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAK%3D%2B-Tu9HxoYxnvc7Q-2cPgXLW3U1Y6edBv1yo%3DD0ar16Aqs6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
