Bug #1370 for Time-Piece: Julian Day implementation flaw

Wed Jul 31 18:54:52 2002 Guest - Ticket created

Subject:

Julian Day implementation flaw

The current "julian_day" implementation is flawed due to first converting to gmtime before performing the operation. The algorithm for calculating the julian day is pre-designed to normalize across all longitudes/timezones (hence all the int() or floor() statements). So "a day", wherever that day resides, regardless of timezone, maps to a particular julian day. By first converting gmtime, for x hours of the day (where x is the gmt offset of your timezone), you will actually be cast into a *different* julian day. Think about it -- for a certain number of hours each day, unless you live in GMT, it will actually be a different date in GMT. This is easily fixed by removing the first line of the julian_day() procedure, the one that converts to gmtime(). I examined several other implementations of julian_day calculations. With the fix above, your implementation matches these other examples. Otherwise, it's off for x hours of the day. Thanks! Matt Sisk

Thu Aug 01 13:52:36 2002 Guest - Correspondence added

From:

msisk [...] cpan.org

Hmm, why say something in two words when twenty would suffice? To recap: There is a 1:1 correspondence between a date (y/m/d) and a julian day. It is only dependent on the year, month, and day -- timezone is irrelevant. So by converting to gmt, you can land on a different date due to tz offset, therefore a different julian day. Matt

Wed Sep 04 08:47:38 2002 Guest - Correspondence added

From:

tjenness [...] cpan.org

[guest - Thu Aug 1 13:52:36 2002]: Show quoted text

> Hmm, why say something in two words when twenty would suffice? > > To recap: There is a 1:1 correspondence between a date (y/m/d) and a > julian day. It is only dependent on the year, month, and day -- > timezone is irrelevant. So by converting to gmt, you can land on a > different date due to tz offset, therefore a different julian day. >

I supplied the patch for Julian day so I feel I should comment. It doesn't make any sense to me that Julian day should depend on timezone - Julian day has no real concept outside of UTC/TT. [especially since Julian day starts at midday rather than midnight so the days change midway through a local day.]. It seemed to be much safer to always return the UT MJD/JD rather than providing for localtime confusion. No astronomical software I know of uses MJD for a specific timezone since it is LST (and by extension longitude) that matters in astronomy and not the timezone (which is a much coarser view of longitude). If MJD is always returned for longitude=0 this should make life easier. Of course, if you are not using MJD for astronomy then your view may be entirely different.

Wed Sep 04 14:30:04 2002 Guest - Correspondence added

From:

msisk [...] cpan.org

Show quoted text

> It doesn't make any sense to me that Julian day should > depend on timezone - Julian day has no real concept > outside of UTC/TT.

I agree, and this is my whole point. As currently written, the JD implementation *introduces* timezone dependencies by first converting to GMT. Every local date/time is associated with the GMT time that kicked off that day. This is true even when GMT has progressed into the *next* day. As an example, I've been working on some sunrise/sunset calculations. Most of these work from the JD, eventually yielding GMT's for the events in question, after which I convert to local time. I often want to start with a localtime object, however, to identify which date is of interest. By using the JD calculation supplied by Time::Piece, I am sometimes calculating sunrise/sunset *not* for the date in question, but for the *next* day -- because, if I happen to be starting with a local time, it's quite possible that *at that moment* it's the next day at GMT. You are correct in stating that JD's are associated with GMT. If you are converting the local date (but we're really only concerned with that y/m/d) from a localtime to GMT first, then you are breaking this association by sometimes calculating JD for the date you intended, other times for the following day. As I've said, I've tested the JD implementation with several other JD implementations, and sure enough, the results are different -- because in all cases these other algorithms care only about y/m/d and not the timezone. Time::Piece, as written, is timezone dependent due to that initial GMT conversion can potentially yield a different y/m/d than you had in mind. It's the nature of Time::Piece to care about localtime vs gmtime. I think there should be a hard assosciation with a specific y/m/d, whether it's local or not, and a particular JD. If you really are interested in the JD for gmtime at any particular moment, then let the user first convert to gmtime to avoid unexpected results. Matt

Sat Sep 14 18:58:34 2002 Guest - Correspondence added

This bug can be closed as a non-issue. I've spoken with Tim; this is a matter of expectation and usage rather than a computational flaw. We need to open up access to the underlying JD calculation for arbitrary year/month/day values. I'll soon be submitting a patch that does this. Thanks, Matt Sisk

Sun Dec 22 06:06:22 2002 msergeant [...] cpan.org - Correspondence added

[guest - Sat Sep 14 18:58:34 2002]: Show quoted text

> This bug can be closed as a non-issue. I've spoken with Tim; this is a > matter of expectation and usage rather than a computational flaw. We > need to open up access to the underlying JD calculation for arbitrary > year/month/day values. I'll soon be submitting a patch that does this.

Marking resolved.

Sun Dec 22 06:06:23 2002 msergeant [...] cpan.org - Status changed from 'new' to 'resolved'