RPM changelog date weirdness

[Michael Schwendt]

On Mon, 17 Sep 2007 13:42:16 -0400, Bill Nottingham wrote:

> > metacity announcement says:
> > 
> > * Tue Sep 11 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
> > - don't dereference a NULL pointer (crash on logout, leading
> >   to weird problems on next login, bug 243761)
> > 
> > rpm says:
> > 
> > * Wed Sep 12 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
> > - don't dereference a NULL pointer (crash on logout, leading
> >   to weird problems on next login, bug 243761)
> 
> It's to do with your timezone settings, and how rpm is interpreting stored
> changelog time. Whether that's a bug or not, I'm not sure.
> 
> Bill

There is a bug (or design problem) somewhere for sure.

I assume because the hours, minutes and seconds are not specified in
the spec file and no TZ is given either, conversion of the date
strings is faulty under special conditions.

I write a spec on Fri Aug 24 (without giving a TZ in the spec), send
it to the buildsys and receive a binary rpm where the changelog is one
day into the future, Sat Aug 25. And the build date is one day before
that. :)

The changelog times are not stored as date strings in the binary RPM
header, but most likely are preconverted to ordinary time() values by
rpmbuild, assuming arbitrary values for the missing h:m:s (possibly
0:0:0).

However, the spec changelog date strings don't contain a TZ, so
rpmbuild running on a build-slave doesn't know *my* TZ offset. It
creates the time() value from my date string for the reference Epoch
time() of the buildsys TZ. When for the buildsys it still is the
previous day of the week compared with my TZ, my date string is one
full day in the future, and the calculated time value reflects that
(with +24 hours). Converting it back to a date string adds the same
weekday+1 here, too.