6
$\begingroup$

I'm trying to calculate the Julian Day, given a UTC year, month and date in the Gregorian calendar. I tried using the formula on Wikipedia, but that doesn't work. Consider 2010-01-31 and 2010-02-01. These dates are exactly one day apart, but their JDNs, according to the formula on Wikipedia, are 2455230 and 2455229, respectively.

In fact, it seems that this issue appears at the beginning and end of February of every year. I wrote a Python script to go through every day from 2010-2020, and these are all similar discrepancies:

ERROR: 2010-01-31 00:00:00 (2455230) vs 2010-02-01 00:00:00 (2455229)
ERROR: 2010-02-28 00:00:00 (2455256) vs 2010-03-01 00:00:00 (2455259)
ERROR: 2011-01-31 00:00:00 (2455595) vs 2011-02-01 00:00:00 (2455594)
ERROR: 2011-02-28 00:00:00 (2455621) vs 2011-03-01 00:00:00 (2455624)
ERROR: 2012-01-31 00:00:00 (2455960) vs 2012-02-01 00:00:00 (2455959)
ERROR: 2012-02-29 00:00:00 (2455987) vs 2012-03-01 00:00:00 (2455989)
ERROR: 2013-01-31 00:00:00 (2456325) vs 2013-02-01 00:00:00 (2456325)
ERROR: 2013-02-28 00:00:00 (2456352) vs 2013-03-01 00:00:00 (2456355)
ERROR: 2014-01-31 00:00:00 (2456691) vs 2014-02-01 00:00:00 (2456690)
ERROR: 2014-02-28 00:00:00 (2456717) vs 2014-03-01 00:00:00 (2456720)
ERROR: 2015-01-31 00:00:00 (2457056) vs 2015-02-01 00:00:00 (2457055)
ERROR: 2015-02-28 00:00:00 (2457082) vs 2015-03-01 00:00:00 (2457085)
ERROR: 2016-01-31 00:00:00 (2457421) vs 2016-02-01 00:00:00 (2457420)
ERROR: 2016-02-29 00:00:00 (2457448) vs 2016-03-01 00:00:00 (2457450)
ERROR: 2017-01-31 00:00:00 (2457786) vs 2017-02-01 00:00:00 (2457786)
ERROR: 2017-02-28 00:00:00 (2457813) vs 2017-03-01 00:00:00 (2457816)
ERROR: 2018-01-31 00:00:00 (2458152) vs 2018-02-01 00:00:00 (2458151)
ERROR: 2018-02-28 00:00:00 (2458178) vs 2018-03-01 00:00:00 (2458181)
ERROR: 2019-01-31 00:00:00 (2458517) vs 2019-02-01 00:00:00 (2458516)
ERROR: 2019-02-28 00:00:00 (2458543) vs 2019-03-01 00:00:00 (2458546)

The JDNs also do not match those on NASA's calculator, as it gives 2010-01-31 to be JD 2455228.

Since Wikipedia isn't always the most reliable resource, I scoured the internet for another website with a formula, and all I found was this page, which gives me the same issue, with a slightly different, step-by-step formula.

Am I doing something wrong? I'm sorry if I am posting this in the wrong community, if there is a better place please let me know.

The code I used to get the list above is below, with the Wikipedia algorithm:

import datetime

prev_d = None
prev = 0

def calc(_d):
    global prev_d
    global prev

    y = _d.year
    m = _d.month
    d = _d.day

    # Formula from Wikipedia
    jd = ((1461 * (y + 4800 + (m - 14) // 12)) // 4 + (367 * (m - 2 - 12 * ((m - 14) // 12))) // 12 - (3 * ((y + 4900 + (m - 14) // 12) // 100)) // 4 + d - 32075)

    if jd - prev != 1:
        print("ERROR: {} ({}) vs {} ({})".format(prev_d, prev, _d, jd))

    prev = jd
    prev_d = _d

# Iterate day-by-day, starting 2010-01-01 UTC
for d in range(1262304000, 1262304000 + 60 * 60 * 24 * 365 * 10, 60 * 60 * 24):
    calc(datetime.datetime.utcfromtimestamp(d))
```
$\endgroup$
12
$\begingroup$

The formula in the wikipedia article explicitly uses integer division with round toward zero. Python's integer division uses round toward negative infinity (i.e., floor).

The wikipedia article formula repeatedly uses (m-14)/12. This evaluates to -1 for months 1 and 2 (January and February), zero otherwise. You can use the wikipedia article formula in python3 if you change every instance of (m-14)/12 in the wikipedia article formula to any of the following:

  • int((m-14)/12)
    The single / performs floating point division. Python's built-in int function rounds toward zero.
  • ((m+9)//12-1)
    The inner (m+9)//12) evaluates to 0 for January and February (m=1 and 2), 1 for all later months.
  • (-1 if m<3 else 0)
    While more verbose, this does a better job of conveying the intent of the wikipedia article's (m-14)/12.
| improve this answer | |
$\endgroup$
7
$\begingroup$

The formula is correct. However, the "problem" is with Python1. https://stackoverflow.com/questions/5535206/negative-integer-division-surprising-result.

Here is the fix to the formula:

jd = (1461 * (y + 4800 + int(float(m-14)/12))) // 4 + (367 * (m - 2 - 12 * (int(float(m-14)/12)))) // 12 - (3 * ((y + 4900 + int(float(m-14)/12)) // 100)) // 4 + d - 32075


1Usually integer division means you drop all the decimal digits... like 4 / 3 = 1.333 = 1. But in Python, integer division means "floor" division which means you go to the smaller integer. Again, example above, 4/3 = 1. Problem is with negative. -4/3 = -1.3333 (which lies between -1 and -2, hence the smaller is -2). They suppose to fix that with Python 3.... but my version 3 still does not work. The work around is convert to float then using int on the answer to drop the decimals. As for the script above, (m-14) always negative no matter what month m is; hence, problem arises.

| improve this answer | |
$\endgroup$
  • 2
    $\begingroup$ You don't need the float() call in Python 3. And in Python 2 you can put from __future__ import division to get Python 3 float division behaviour with integer operands. Also, it would be neater & more efficient to do this calculation in two steps, rather than repeating the month reduction 3 times, eg q = int((m - 14) / 12) $\endgroup$ – PM 2Ring Jul 17 at 5:30
  • $\begingroup$ Mine is python 3.73.... and still integer division doesn't work... $\endgroup$ – Huy Pham Jul 17 at 6:48
  • 1
    $\begingroup$ I also get the same results as you in Python 3, but I don't understand what "the problem is with Python" really means. Can you add a little more explanation about what it is about the script in the question that is wrong and what exactly is fixed here? Thanks! $\endgroup$ – uhoh Jul 17 at 8:49
  • 1
    $\begingroup$ Usually integer division means you drop all the decimal digits... like 4 / 3 = 1.333 = 1. But in Python, integer division means "floor" division which means you go to the smaller integer. Again, example above, 4/3 = 1. Problem is with negative. -4/3 = -1.3333 (which lies between -1 and -2, hence the smaller is -2). They suppose to fix that with Python 3.... but my version 3 still does not work. The work around is convert to float then using int on the answer to drop the decimals. As for the script above, (m-14) always negative no matter what month m is; hence, problem arises. $\endgroup$ – Huy Pham Jul 17 at 12:40
  • $\begingroup$ @HuyPham -- Re "They suppose to fix that with Python 3" Fix what? Python3 was introduced a decade before Guido van Rossum stepped down as the Python BDFL. From Van Rossum's perspective, python did integer division correctly from day one; there was nothing to fix. He viewed the Fortran implementation of integer division as faulty, and that included the C family of languages that followed the Fortran implementation. $\endgroup$ – David Hammen Jul 18 at 11:25
3
$\begingroup$

Adding to the answers above: One of the problems here is that Julian Day Numbers start at noon of a particular Gregorian Date. For the dates under consideration

  • January 31, 2010 starts on JDN 2455227.5
  • February 1, 2010 starts on JDN 2455228.5

You mentioned needing a reliable source for date algorithms. I recommend https://www.researchgate.net/publication/316558298_Date_Algorithms (an earlier version is archived at https://web.archive.org/web/20090405221644/http:/mysite.verizon.net:80/aesir_research/date/date0.htm) which is specifically designed to help programmers write fast date algorithms. It includes specific dates needed to check your program, discusses integer vs. float, word length, and other issues. The document also gives proofs for variations of all the algorithms.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.