[CentOS-devel] RPM date strangeness (was:[CentOS] rpmbuild date shift)

Tue May 19 12:41:18 UTC 2009
Jeff Johnson <n3npq at mac.com>

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 ...

>
> 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;
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.

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).

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.

But rpm *will* get the day of week correct even if its incorrectly
entered into the spec file %changelog.

hth

73 de Jeff