`UDN` uses irreversible JDNs. about gedkeeper

[Serg-Norseman]

Time - no problem! :)
I'll just suggest this: I think you don't have to deal with the change of algorithms and format of IEEE 754 doubles. If you want to continue this theme: then, IMHO, you need to develop integer JD and formulas from Wikipedia. I'll too try to find such formulas for missing calendars.

[ruslangaripov]

you don't have to deal with the change of algorithms and format of IEEE 754 doubles

Why not? We have already broken one format (double word). Why wouldn't we break an another one? 😈 If we could, of course.

[Serg-Norseman]

Check this out, now unexpectedly found: http://aa.quae.nl/en/reken/juliaansedag.html

[Serg-Norseman]

Fixed by 49999c9

[Serg-Norseman]

Maybe close the question? How many thought - the new bits are not needed; the reversibility of now generally there, although not very correct.

[ruslangaripov]

To be perfectly frank, we did not fix the problem 😈

The most perfect way to fix it, is to implement the algorithms from Wikipedia operating with integer values. Thus, we eliminate usage of floating-point values. Of course, this will require some time, but I'm ready to lose it, because the game is worth the candle -- we'll get reversible JDN values.

If we select "cracking IEEE Standard 754 standard", we pick yet another an unsteady way, where we change underlying data storage. Just as we already did. But because we have already did that, we may go further and try to use double precision floating-point values instead of current 32-bit value.

So, here is my decision: the current UDN implementation does not give irreversible JDNs. While it must. If GEDKeeper can live with that -- this make our programmer lives easy 😈 But before we might close this ticket completely, we must try to fix it. I'll try to implement the both solutions (integer algorithms and 64-bit floating-point values) at the bitbucket repository. Just give me a time, please!

[ruslangaripov]

What I've implemented using http://aa.quae.nl/en/reken/juliaansedag.html:

1. JDNs made from dates in Gregorian and Julian calendars are completely reversible.
2. JDNs made from dates in Islamic calendar are completely reversible (and it looks like, they were).
3. JDNs made from dates in Jewish calendar are reversible... occasionally (while the current 'Fourmilab Calendar Converter' always gives reversible values for Jewish calendar).

For example,
Jewish date -> JDN -> Jewish date
4682/3/18 -> 2057986 -> 4682/3/18 (no error, okay)
4684/7/1 -> 2058441 -> 4684/7/1 (fine)
3761/10/18 -> 1721426 -> 3761/10/-12 (oops 😕)
3761/12/1 -> 1721468 -> 3761/11/1 (not good again)
3762/11/1 -> 1721791 -> 3762/10/27 (what's that?)
3762/12/2 -> 1721822 -> 3762/11/29 (:finnadie:)
3762/13/29 -> 1721879 -> 3762/13/26 (:bomb:)
3763/1/1 -> 1722234 -> 3763/1/1 (starting from this date everything becomes correct)