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?
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?
While all other date-parts *are* influenced by different :zone values...
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).
BOOST_CHECK_EQUAL(parseDate("Thu, 1 Jan 1970 00:00:00 ut"),
Date(0 /* timestamp */, 0 /* informational timezone offset */));
BOOST_CHECK_EQUAL(parseDate("Thu, 1 Jan 1970 01:00:00 +0100"),
Date(0 /* timestamp */, 3600 /* informational timezone offset */));
Of course, we have additional other tests.
Kind regards,
Hannah.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve