> 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.
A bit delayed on my reply but I would love to see what you come up with. Let me know if there is anything else I can help with. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Dec 20, 2016 at 2:14 AM, Kip Cole <[email protected]> wrote: > 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 <jose.valim@ > plataformatec.com.br> 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_fgPO >> Sa39eG0CAwa0y3F3oMvGGw%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 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. > To unsubscribe from this group and all its topics, 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 > <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. > > > -- > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/1190677D-C0A7-4F33-8CD2-A5B7EC32835D%40gmail.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/CAGnRm4JBze9basD93GwzUtfAeeiV1uaozC_wMeJm1fG4ChU7hg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
