Julian Day support missing

[bartolsthoorn]

I think Moment.js is missing a method to convert a datetime to a Julian Day. The JD-system is used by astronomers.

[Xotic750]

The big problem with such support is that you do not need to go far into the future (or past) before the numbers become bigger than Javascript can handle, you then need an arbitrary-precision arithmetic library. Javascript's Date object is also limited to 100,000,000 days either side of 1 Jan 1970. So it is fine so long as you are doing calculations into the near future or near past. Other problems happen when you start using moment durations and addition/subtraction routines as these perform calculations on estimates that are of little or no use when performing astronomical calculations. I came across these exact problems when I tried to use moment as a base for such calculations, this resulted in me creating a library from scratch which is not based on Javascript's date object. This is not a fault of moment, so to speak, but moment would need to discard the use of the Date object and handle arbitrary-precision arithmetic. The library that I am working on for such calculations is AstroDate. Maybe some day moment will be able to use such a library as a replacement to Date, but it will be a while. Until then, the strength of moment is its date parsing and formatting abilities, and its ability to perform humanised approximations.

[ichernev]

According to the wikipedia article 1 Jan 2013, is around 2M days. I think JavaScript can handle numbers around 2M, it uses 64 bit floats (I guess), so 15 digits are a given. Maybe for seconds .. not that good :) I guess a code that handles JD can be implemented, and then arbitrary precision numbers can be plugged in later, if users really need it.

[Xotic750]

For support of accurate Julian Dates (Julian Day Number + time as a fraction of day), you require a number to 9 decimal places (for millisecond support). 15 significant figures is the maximum to convert from a Javascript number to arbitary-precision. This means a min and max integer part of 999999 which equates to a Gregorian date range of December 29, -7452 to October 20, -1976, not very useful. Without arbitray-precision any Javascript numbers are subject to floating point errors and therefore any calculations become inaccurate, but an approximation may be good enough for some people. A better suggestion would be to supply the Modified Julian Date if you are not going to use arbitrary-precision, as this will at least have a useable date range that can be converted to arbitrary-precision but is still subject to floating point errors as a Javascript number. The floating point errors are acceptable if your calculations require nothing more than an accuracy of +- some milliseconds (and 'bubble' it). So, without arbitrary precision moment will not be able to round trip a dateTime to (M)JD and then (M)JD back to a dateTime accurately. It's worth noting that the example given in wikipedia is

The Julian Date (JD) of any instant is the Julian day number for the preceding noon plus the fraction of the day since that instant. Julian Dates are expressed as a Julian day number with a decimal fraction added.[2] For example, the Julian Date for 00:30:00.0 UT 1 January 2013 is 2456293.520833.[3]

Which when round tripped it gives 2013-01-01T00:29:59.971Z

Whereas with 9 dp 2456293.520833334 round tripped gives 2013-01-01T00:30:00.000Z

Good job they didn't use 00:00:00.0 UT 1 January 2013 as the round trip would have been a different year.

So this drop in accuracy would allow you to convert from a Javascript number to arbitrary-precision, but you have already sacrificed accuracy in doing so.

[ichernev]

Closing this for now. Can be implemented using #1454 (in the future), the accuracy problem is a real one -- I guess using 2 numbers (one for days, another for milliseconds) would do the trick.

[bartolsthoorn]

Okay, thanks!

[voikester]

Any updates on this?

[rhyolight]

I would have used this feature if it existed today.

[boriskogan81]

+1

[michaelKurowski]

+1 useful for astronomical purposes

[jacobbogers]

old ticket, but is it implemented?