José, it seems appropriate to post a PR for Calendar on the first day of the year :-) https://github.com/elixir-lang/elixir/pull/5603 <https://github.com/elixir-lang/elixir/pull/5603>
This embodies the idea of a canonical integer date representation. I have used the principles embodied in Calendrical Calculations by Dershowitz and Rheingold since I think that provides a very solid and well-proven basis for calendar creators. I added a Calendar.Julian as one example. I took the opportunity to add support for DateRange and the Enum protocol, a Date.diff/2 function and the standard set of kday functions. Happy New Year to all. > On 30 Dec. 2016, at 1:03 am, José Valim <[email protected]> > wrote: > > > 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 <http://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] > <mailto:[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] >> <mailto:[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] > <mailto:[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 > <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/CAGnRm4JBze9basD93GwzUtfAeeiV1uaozC_wMeJm1fG4ChU7hg%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JBze9basD93GwzUtfAeeiV1uaozC_wMeJm1fG4ChU7hg%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/875866A7-8852-4AD9-991B-692E629076E7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
