José, Paul, thanks both.
José: option (b) would seem better to me as well - and it means my work is not
(yet?) in vain :-)
Paul: I’m working on calendrical calculations for Elixir and want to be
Calendar behaviour compatible. I think some small and compatible adjustments
to Date and DateTime/NaiveDateTime can allow all of the calendars in
Calendrical Calculations to be developed in accordance with the behaviour
except those that don’t reduce to a {y, m, d} tuple - like the Balinese
calendar. Including Date.to_fixed() would be a necessary part of that as a way
of allowing date comparisons and calendar conversions. Which can be done with
no performance impact to Calendar. ISO I believe.
With the guidance from José in this thread I can finish up development now and
see if the community thinks its worth a PR. Of course calendars beyond the
standard ISO would be a separate package(s) and any changes will have to have
the same or better performance profile and pass all current tests too.
Perhaps its a quirk, but I happen to really like calendar stuff - its the
relationship to human history I think.
Oh, and I’m not proposing the
> On 20 Dec 2016, at 9:51 AM, Paul Schoenfelder <[email protected]>
> wrote:
>
> 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]
> <mailto:[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]
> <mailto:[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
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe
> <https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> [email protected]
> <mailto:[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
>
> <https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tu9HxoYxnvc7Q-2cPgXLW3U1Y6edBv1yo%3DD0ar16Aqs6A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <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/1190677D-C0A7-4F33-8CD2-A5B7EC32835D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
