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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20090519/8c974c8a/attachment-0007.sig>