Calendrical Calculations

77 views
Skip to first unread message

Paul Schoenfelder

unread,
Jul 13, 2017, 7:17:50 PM7/13/17
to elixir-l...@googlegroups.com
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
 

José Valim

unread,
Jul 13, 2017, 8:05:50 PM7/13/17
to elixir-l...@googlegroups.com
Thanks Paul, this is just before the v1.5.0 release, so the timing is also positive.

I believe we have made many decisions along the way that moved us considerably away from Calendrical Calculations, especially in supporting only year-month-day / hour-min-sec calendars and the rata die representation itself.

Given the information above and the fact our "rata die" is no longer the "by the book" definition, I believe we should change the name to something more independent.



José Valim
Skype: jv.ptec
Founder and Director of R&D

--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Ts6_wH6R_yUL-Uur-rrjQ20E9DmnZji7Y9NP1fDTvRYKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Paul Schoenfelder

unread,
Jul 13, 2017, 8:17:22 PM7/13/17
to elixir-l...@googlegroups.com
That's great to hear! Sorry for hitting the panic button. I'll have to catch up on the recent changes sometime soon, definitely interested to see what approach was taken!

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JntWiML5-ZhFT%2BF0bjMqvUDkNnfA3nA41QzwZxjB7bDw%40mail.gmail.com.

José Valim

unread,
Jul 14, 2017, 5:37:20 AM7/14/17
to elixir-l...@googlegroups.com



José Valim
Skype: jv.ptec
Founder and Director of R&D

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

--
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 elixir-lang-core+unsubscribe@googlegroups.com.

--
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 elixir-lang-core+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tuk5EVToDwg1UhVacwWxNnA%2BZU3jhZ5T%3DY9c8oCKPLFBg%40mail.gmail.com.

Wiebe-Marten Wijnja

unread,
Jul 14, 2017, 7:28:16 AM7/14/17
to elixir-lang-core
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

Paul Schoenfelder

unread,
Jul 14, 2017, 12:26:25 PM7/14/17
to elixir-l...@googlegroups.com
> 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


--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e2942790-cdd0-41ef-81c6-a412e9069784%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages