RPM changelog date weirdness

[Michael Schwendt]

$  rpm -qi sylpheed|grep 'Build Date'
Release     : 3                             Build Date: Fri 24 Aug 2007 01:21:16 PM CEST

$ grep -B2 POP3 sylpheed.spec
%changelog
* Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).

But:

$ LANG=C rpm -q sylpheed --changelog|head -3
* Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).

*All* entries are off by one day forward. Bug or PEBKAC?

[Peter Jones]

Michael Schwendt wrote:
> $  rpm -qi sylpheed|grep 'Build Date'
> Release     : 3                             Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
>
> $ grep -B2 POP3 sylpheed.spec
> %changelog
> Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
>
> But:
>
> $ LANG=C rpm -q sylpheed --changelog|head -3
> Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
>
> *All* entries are off by one day forward. Bug or PEBKAC?

What's your timezone set to?

[Michael Schwendt]

On Wed, 29 Aug 2007 14:45:16 -0400, Peter Jones wrote:
> Michael Schwendt wrote:
> > $  rpm -qi sylpheed|grep 'Build Date'
> > Release     : 3                             Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
> >
> > $ grep -B2 POP3 sylpheed.spec
> > %changelog
> > Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> > Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
> >
> > But:
> >
> > $ LANG=C rpm -q sylpheed --changelog|head -3
> > Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> > Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
> >
> > *All* entries are off by one day forward. Bug or PEBKAC?
>
> What's your timezone set to?

$ cat /etc/sysconfig/clock 
ZONE="Europe/Berlin"
UTC=true
ARC=false

[Michael Schwendt]

On Wed, 29 Aug 2007 20:56:21 +0200, Michael Schwendt wrote:
> On Wed, 29 Aug 2007 14:45:16 -0400, Peter Jones wrote:
> > Michael Schwendt wrote:
> > > $  rpm -qi sylpheed|grep 'Build Date'
> > > Release     : 3                             Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
> > >
> > > $ grep -B2 POP3 sylpheed.spec
> > > %changelog
> > > Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> > > Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
> > >
> > > But:
> > >
> > > $ LANG=C rpm -q sylpheed --changelog|head -3
> > > Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
> > > Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
> > >
> > > *All* entries are off by one day forward. Bug or PEBKAC?
> >
> > What's your timezone set to?
>
> $ cat /etc/sysconfig/clock 
> ZONE="Europe/Berlin"
> UTC=true
> ARC=false

Fedora 7 is affected, too. All F7 Test Updates, for example,
don't pass this check.

The Test Update announcements print changelog dates that doesn't
match the rpm --changelog query, which is off by one into the
future compared with what the spec file contains. E.g.:

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)

yum announcement says:

* Mon Sep 10 2007 Seth Vidal <skvidal at fedoraproject org> - 3.2.5-1
- 3.2.5
- prune unnecessary patches

rpm says:

* Tue Sep 11 2007 Seth Vidal <skvidal at fedoraproject org> - 3.2.5-1
- 3.2.5
- prune unnecessary patches

[Bill Nottingham]

Michael Schwendt ([e-mail]) said:
> 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

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

[Bill Nottingham]

Michael Schwendt ([e-mail]) said:
> 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).

They're stored as seconds-since-the-epoch - see CHANGELOGTIMES
in an rpm query.

Bill

[Peter Jones]

Bill Nottingham wrote:
> Michael Schwendt ([e-mail]) said:
> > 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).
>
> They're stored as seconds-since-the-epoch - see CHANGELOGTIMES
> in an rpm query.

And more specifically, the date in the specfile is interpreted as noon 
on that day, UTC.

[Bill Nottingham]

Peter Jones ([e-mail]) said:
> Bill Nottingham wrote:
> > Michael Schwendt ([e-mail]) said:
> > > 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).
> >
> > They're stored as seconds-since-the-epoch - see CHANGELOGTIMES
> > in an rpm query.
>
> And more specifically, the date in the specfile is interpreted as noon on 
> that day, UTC.

... which means you *shouldn't* be able to get an off-by-one-date, barring
being located in the South Pacific and weirdness with leap seconds.

Bill

[Michael Schwendt]

On Thu, 20 Sep 2007 16:16:39 -0400, Bill Nottingham wrote:
> Peter Jones (pjones redhat com) said:
> > Bill Nottingham wrote:
> > > Michael Schwendt ([e-mail]) said:
> > > > 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).
> > >
> > > They're stored as seconds-since-the-epoch - see CHANGELOGTIMES
> > > in an rpm query.
> >
> > And more specifically, the date in the specfile is interpreted as noon on 
> > that day, UTC.

noon is midday, but Midnight Commander displays 00:00:00 for the changelogs.
(perhaps that's another bug in mc, though)
> ... which means you *shouldn't* be able to get an off-by-one-date, barring
> being located in the South Pacific and weirdness with leap seconds.

Since there is no time zone specified in the changelog, the off-by-one
error *could* be the result of interpreting and converting the
specfile in different time zones, not accounting for a change in the
weekday if the implicit time zone offset is large enough.

Contrary to my first post in this thread, I *currently* don't get the
off-by-one error for "sylpheed", but for e.g. "yum" (Sep 10 -> Sep 11)
and (Sep 11 -> Sep 12).

With sylpheed I don't see a time zone offset that is large enough
and which would cause a constant off-by-one error:

http://koji.fedoraproject.org/koji/buildinfo?buildID=15872

build-job started: Fri, 24 Aug 2007 04:10:10 MST
  that is UTC-7 for Phoenix/AZ (or UTC-5 for Raleigh/NC)
  in Germany it is UTC+1 plus daylight-saving
  specfile also contains "Fri 24 Aug"
  => the time zone difference of +8/+9 hours (for AZ) doesn't matter,
  => it doesn't change the weekday

Even for Fri 24 Aug 12:00 UTC-7, the converted time() value
  would end at Fri 24 Aug 20:00 UTC+1 when converted back.

For the yum and metacity builds, the offset is even less (<= 2 hours
inside the U.S.), but still they are off by one here currently. :)

[Alan Cox]

On Thu, Sep 20, 2007 at 04:16:39PM -0400, Bill Nottingham wrote:
> ... which means you *shouldn't* be able to get an off-by-one-date, barring
> being located in the South Pacific and weirdness with leap seconds.

Until the year 2800 anyway...