RPM changelog date weirdness

[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 (mschwendt.tmp0701.nospam at arcor.de) 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. :)