> To be more exact, I used the paper of the same name that can be found here: http://www.cs.tau.ac.il/~nachum/papers/cc-paper.pdf as authorative reference; the book supposedly contains a lot more information about a lot more calendars.
Yeah I happen to own the book, and didn't know there was a paper publicly available - it seems like the book is much more fleshed out. > The 'Rata Die' format indeed has at least for different meanings (i.e. offset in days from four different epochs), and was used by others even before Calendrical Calculations. Interestingly, in the paper the term 'absolute day number' is used (and 'Rata Die' is nowhere to be found). "Rata Die" is mentioned in the book, but I was pretty sure it wasn't a thing they came up with (the book may even say so, I don't recall for sure) > The conversion to/from the 'Gregorian day number' type of Rata Die for Calendar.ISO is not based on the algorithms of Calendrical Calculations, but on the algorithms used by the Erlang `:calendar` module (initially, these methods were called directly, but now they have been adapted to Elixir code to permit working with negative datetimes in the near future). Where `:calendar` got its inspiration I cannot say; part of the functionality is similar to the Lisp-code that Dershowitz and Rheingold propose in the Calendrical Calculations paper, but much of it is entirely different as well. I think even if `:calendar` was inspired by the paper/book, there's nothing wrong with that as long as it differs in a significant way in implementation. > Working with day fractions in the way we do is novel; I do not know of any other place where in-day times are represented in such a precise format. I'm actually fairly certain this is a method covered in the book, I'll have to go back and check, but if you are doing effectively a clean-room implementation, I don't think it matters at all. > Converting between time formats is novel as well. I'm curious about this, could you point me to a PR or issue? > So I am happy to say that our implementation is very distant from the Lisp-implementation shown in the Calendrical Calculations paper. :-) There is a Java implementation too! :) Paul On Fri, Jul 14, 2017 at 6:28 AM, Wiebe-Marten Wijnja < [email protected]> wrote: > Thank you very much for bringing this to our attention. > I was not aware that the work of Dershowitz and Rheingold was released > under such a restrictive license. > > Calendrical Calculations has definitely been used as authorative > reference, but not as a 1:1 source reference: > To be more exact, I used the paper of the same name that can be found > here: http://www.cs.tau.ac.il/~nachum/papers/cc-paper.pdf as authorative > reference; the book supposedly contains a lot more information about a lot > more calendars. > > - The 'Rata Die' format indeed has at least for different meanings (i.e. > offset in days from four different epochs), and was used by others even > before Calendrical Calculations. Interestingly, in the paper the term > 'absolute day number' is used (and 'Rata Die' is nowhere to be found). > - The conversion to/from the 'Gregorian day number' type of Rata Die for > Calendar.ISO is not based on the algorithms of Calendrical Calculations, > but on the algorithms used by the Erlang `:calendar` module (initially, > these methods were called directly, but now they have been adapted to > Elixir code to permit working with negative datetimes in the near future). > Where `:calendar` got its inspiration I cannot say; part of the > functionality is similar to the Lisp-code that Dershowitz and Rheingold > propose in the Calendrical Calculations paper, but much of it is entirely > different as well. > - Working with day fractions in the way we do is novel; I do not know of > any other place where in-day times are represented in such a precise format. > - Converting between time formats is novel as well. > - Most of the Calendrical Calculations paper (and as far as I know the > book) goes on about converting other calendars to the Rata Die format at > hand, and how the dates of certain holidays can be predicted, neither of > which we do in Elixir's standard library. > > So I am happy to say that our implementation is very distant from the > Lisp-implementation shown in the Calendrical Calculations paper. :-) > > > ~Qqwy/Wiebe-Marten > > On Friday, July 14, 2017 at 1:17:50 AM UTC+2, Paul Schoenfelder wrote: >> >> Hey all, >> >> So I'm concerned about something I've noticed recently. I've seen >> multiple mentions of this book (Calendrical Calculations by Reingold and >> Dershowitz) and use of it's algorithms in Elixir's Calendar implementation, >> and I know I mentioned it back when I first suggested the idea of using >> something like the "rata die" concept to support multiple calendars. The >> problem is that the code and algorithms in the book are restrictively >> licensed. I wrote to Professor Reingold early last year (May-ish) about >> using the ideas from the book in Timex to implement support for multiple >> calendars as well as implement some of the alternate calendars, >> particularly the lunar ones. I heard back from Professor Dershowitz fairly >> quickly, and the gist was that I was free to use it for anything >> non-commercial, as long as it was appropriately attributed and restricted >> to non-commercial use. Because of this, I chose to avoid using it's >> contents as an implementation reference in Timex because it is used in >> commercial software. Below is the reply I received from him: >> >> Dear Paul, >>> >> >> >> >>> Thank you for your generous thanks. >>> Feel free to use our programs for your free (noncommercial) use, >>> provided proper attribution is given to Calendrical Calculations. >>> Please send us a link when you do publish anything. >>> But if you distribute it, it must preserve the attribution and >>> restriction to non-commercial usage. >>> >> >> >> Best, >>> Nachum >>> >> >> Recently in some PRs I happened to read through, I saw mention that the >> contributor was implementing the code using the algorithms from Calendrical >> Calculations. I think that could represent a real issue - Elixir is used in >> commercial software, and it seems to me like this could open up the >> language (or worse, the authors) to some kind of legal trouble. >> >> I haven't been reading calendar-related PRs in depth for some time now >> because I've been pretty busy, so I don't know how much we've leaned on the >> book in Elixir. The use of the "rata die" concept is probably less >> troublesome since it's implementation is very different depending on what >> date you choose for the conversion, but if we've followed the algorithm >> from the book 1:1, then I think we'll have to change it. >> >> I apologize for not bringing this up sooner, it didn't occur to me until >> today the ramifications - up until now I had just assumed we were using it >> as an authoritative reference on how to build calendar code, rather than >> using it as a source reference. >> >> If I'm mistaken about how we've been using it, awesome! I just want to >> make sure we're in the clear :) >> >> Paul >> >> > -- > 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/e2942790-cdd0-41ef-81c6- > a412e9069784%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/e2942790-cdd0-41ef-81c6-a412e9069784%40googlegroups.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-TueQqicOcwzYOb8q5MwFsPsygH1y9xuxTsc8TwGrhquig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
