Hi NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com,
--On August 21, 2009 1:18:01 PM -0700
NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com
wrote:
> The error is in the sample code provided for Julian day calculations. The
> original specification called for the use of Julian days, but this was
> subsequently changed to modified Julian days (mostly because they start
> and end at mignight, as opposed to the noon start time for Julian days).
>
> However, when this was done the sample code was not updated to include
> the additional 2400000.5 factor. So the routines produce Julian day
> results, not modified Julian days.
>
> Normally I'd simply fix this with an RFC errata and not bother the WG
> about it. However, in this case we're talking about sample code, which as
> we all are painfully aware has the IETF completely wrapped around the
> axle.
>
> In particular, given a revision is needed, it may make sense to use this
> opportunity to republish the RFC and also change the appendix to call
> these routines "code components", meaning they are free from copyright
> restrictions and can be freely copied.
>
> So what do people think? I'm happy with either approach - republishing is
> more work, but fixing IPR issues may be worth it.
How wide spread is the use of Julian days in implementations right now?
Interesting question. The usual thing Julian date conversion routines
are used for is stuff like "what day is 104 days past X". If you
have Julian day routines lying around, this is simply:
juldate(julday(X) + 104)
But in such appliccations it doesn't matter if modified or regular dates
are used - the offsets cancel out.
Sieve is a little different since there's no functionality (or much need
for functionality) to turn a (modified) Julian day into a date. The thing
I use Julian dates for, and I've seen others use them for, is comparisons
that only take the day into account. And again, as long as the offsets
are consistent, it doesn't matter whether you're using MJD or JD.
Of course if you've hard coded a constant date based on the result of the
routines in the RFC, then that's going to break. But scripts that do this tend
to be transitory in nature, almost by definition.
But again, the main problem with regular Julian days is the fact that they
change at noon, not midnight. People may have used the routines in the
appendix thinking they were getting MJD when they weren't (one big integer
looking more or less like another), but I doubt anyone was sufficiently
confused to have them tick over at noon. So what we've probably ended up
with is a Julian day value with a 0.5 offset.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve