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

Tue May 19 13:53:57 UTC 2009
Ralph Angenendt <ra+centos at br-online.de>

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>