You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
new Date() exhibits legacy undesirable, inconsistent behavior with two-digit year values; specifically, when a new Date() call is given a two-digit year value, that year value does not get treated as a literal year and used as-is but instead gets interpreted as a relative offset — in some cases as an offset from the year 1900, but in other cases, as an offset from the year 2000.
So dates dates that should have a year value from 0 through 99 (1 BC through 99 AD) are incorrectly rendered as 1900 through 1999.
Year value for the output Date object should instead be set using the setUTCFullYear() method.
Also, I think the package documentation should somehow make note of the date limits of the calculation. The Python package PyMeeus which appears to implement the same algorithm works for year values -1000 through 3000 (1001 BC through 3000 AD) and throws an exception otherwise.
The text was updated successfully, but these errors were encountered:
The method
getDateFromJulianDay
passes the year value to thenew Date()
constructor, which has a documented legacy behavior with two-digit year values:So dates dates that should have a year value from 0 through 99 (1 BC through 99 AD) are incorrectly rendered as 1900 through 1999.
Year value for the output
Date
object should instead be set using thesetUTCFullYear()
method.Also, I think the package documentation should somehow make note of the date limits of the calculation. The Python package PyMeeus which appears to implement the same algorithm works for year values -1000 through 3000 (1001 BC through 3000 AD) and throws an exception otherwise.
The text was updated successfully, but these errors were encountered: