Jeff Johnson wrote:
On May 19, 2009, at 7:29 AM, Ralph Angenendt wrote:
Yay! I invented a time machine! (or someone did).
;-) Well, rpm *will* correct the day of the week for you in case you've forgotten. Try and see ...
Hmmm. * Tue May 19 2009 looks correct to me, the calendar applet on my Desktop tells me the same, as does my mobile phone.
Something is not right here. Is this something to worry about? How and why does that happen? Why are there even calculations on the date line in a changelog?
There aren't any calculations, but there are two conversions involved.
During build a straightforward date/time parser (hint: which doesn't use day of week) parses the string in the spec file into a struct tm time;
I'm still not getting your hint :)
Note that %changelog cannot specify a timezone. Silly but true.
Then these transforms are applied to attempt to get UTC:
*secs = mktime(&time); if (*secs == -1) return -1; /* determine timezone offset */
/*@-nullpass@*/ /* gmtime(3) unlikely to return NULL soon. */ timezone_offset = mktime(gmtime(secs)) - *secs; /*@=nullpass@*/
/* adjust to UTC */ *secs += timezone_offset;
and what *should* be seconds since epoch in UTC is stored in header. But since there was no unambigous way to specify timezone, there's the usual timezone shifting implicit in how build machine (or mock) is configured.
Meaning: If my mock runs in EDT (as it seemingly does for me), finds out that it is at 7:29 am, it then shifts to UTC (4 hours ahead), making it 11:29 am then. This still is Tue May 19 2009 in this case. Am I correct with that assumption?
Then rpm -qp --changelog converts from seconds back to display time using the "standard" conversion
const char * strftimeFormat = _("%a %b %d %Y"); ... struct tm * tstruct; char buf[50];
/* this is important if sizeof(rpmuint64_t) ! sizeof(time_t) */ { time_t dateint = he->p.ui64p[0]; <== this is seconds
since epoch tstruct = localtime(&dateint); } buf[0] = '\0'; if (tstruct) (void) strftime(buf, sizeof(buf) - 1, strftimeFormat, tstruct);
So in essence, the spec file is parsed wrto one local time zone, and -- changelog is displayed wrto another local time zone, and what's in the header is in UTC (assuming the build system was configured correctly and the spec file was written in local time).
This is what I don't get. I'm UTC +0200 - why do I get a shift of date to the next day in there, essentially leaving me on May 20th? Why don't I get that when I'm on BST (UTC +0100)?
I wouldn't worry too much. The real flaw is in the %changelog parser, and heaven forbids changing to include a timezone indicator in %changelog entries without collusion between God and the Devil.
Okay. We were worried that other parts of the rpm might also be affected in one or the other way.
But rpm *will* get the day of week correct even if its incorrectly entered into the spec file %changelog.
I still don't get that. Care to expand on it? I still assume that I entered the weekday correctly :)
Cheers,
Ralph