Hello!
On Thu, Sep 17, 2009 at 09:32:37AM -0700, Ned Freed wrote:
RFC 5260 states
"julian" => the Modified Julian Day, that is, the date
expressed as an integer number of days since
00:00 UTC on November 17, 1858 (using the Gregorian
calendar). This corresponds to the regular
Julian Day minus 2400000.5. Sample routines to
convert to and from modified Julian dates are
given in Appendix A.
Do I understand it right that date-part "julian" ignores any timezones
that way?
I'm not entirely clear on what you mean here, but if you're talking about
simply dropping any time zone component before converting to Julian day, then
no, that makes no sense.
My question was this:
Date: ...
Does
if date :zone "+0100" "Date" "julian" "..."
and
if date :zone "-2300" "Date" "julian" "..."
make any difference, given the same mail header?
Ah. That makes more sense then. The answer is no - since a Julian day is an
interval between two points in time, not an absolute representation of a
particular point in time (unlike all the other date-parts) the use of :zone
ends up having no effect.
Of course this suggests a shortcut ot not applying :zone when the date-part is
"julian", but I'm skeptical the optimization is worth it.
I.e. does "julian" in effect cause the test to "ignore" :zone; because
if I "translate" the same date-time to a different timezone, its
"distance" to the epoch (in this case, the one of the Modified Julian
Date) keeps staying the same?
:zone ends up being effectively ignored because the Julian day calculation
requires normalization to GMT in order to get the internal right. So you can
apply the :zone if you want but any effect it has will be wiped out by the
subsequent normalization to GMT Julian day calculations require.
While all other date-parts *are* influenced by different :zone values...
Yes.
Julian day is defined as the integral number of days between *two* points in
time. You're confusing the specification of the time zone for the first -
fixed
- one of these points with the specification of the time zone for the second.
I don't confuse that, I think. I think you misunderstood my question.
[...]
So I could calculate "julian" by using an Unix timestamp,
dividing it by 86400 and adding 39610 to it, without any timestamp
corrections?
I don't know what you mean by "timestamp corrections", but if by "Unix
timestamp" you mean a time_t value expressing the number of seconds since Jan
01 1970 00:00 UTC, then yes, this should get you the modified Julian date.
However, this ignores how you got to that "Unix timestamp" in the first
place.
If you did so by incorporating any time zone offset in the original time
value
into the calculation, then it's all good. If, however, you simply dropped any
zone information, then the result can be incorrect.
Putting this in terms of standard C library functions, it's the difference
between calling mktime (correct) to get that time_t value and timegm (wrong).
In fact, we use timegm, but then apply the time zone offset ourselves.
We have tests in order to check that that's correct. mktime uses the
*locale*'s timezone which isn't the timezone of the mail header's
date-time. We keep the original timezone value of the mail header in a
separate field (which will be needed for :originalzone).
Yes, use of mktime requires that you piddle around with the time zone setting
becauuse it won't be read from the structure. Bad API design... And that can
have thread safety issues. That said, I've also seen timegm implemented by
zeroing out the currently active time zone, calling mktime, and then restoring
it. So it may have the same problem.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve