RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1313804 - Leap year handling broken for rsyslog, timestamps issue one day earlier
Summary: Leap year handling broken for rsyslog, timestamps issue one day earlier
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rsyslog7
Version: 6.6
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1313898
TreeView+ depends on / blocked
 
Reported: 2016-03-02 11:36 UTC by Peter Portante
Modified: 2016-10-26 09:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1313898 (view as bug list)
Environment:
Last Closed: 2016-10-26 09:43:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Peter Portante 2016-03-02 11:36:18 UTC
From http://lists.adiscon.net/pipermail/rsyslog/2016-March/042159.html:

-----

Hi all,

I just wanted to let you know that we have found an issue with the
unixtimestamp formatting option in leap years. The problem started on
March, 1st and will persist till the end of the year. The timestamp is
one day in the past.

A patch is available here, it shall probably work with almost all
rsyslog versions:
  https://github.com/rgerhards/rsyslog/commit/ffb321f1698a971e0acda48cafa97bb344cf0829

Full details can be found in this issue tracker:
   https://github.com/rsyslog/rsyslog/issues/830

Note that I will NOT release a 8.16.1 version for this fix. Usually, I
would have done so, but the 8.17.0 release is due next Tuesday and
will probably available as RC on friday. Given the fact that I would
need at least one additional day to craft 8.16.1, I don't think this
makes much sense.

Distro packages (and other users as well, of course) can apply
above-mentioned short patch. I actually suggest to do so, as this
problem exists, I think, in all versions supporting the
"unixtimestamp" formatting option (side-note: v5.8 does not have this
option).

Rainer

-----


Note that this appears to be a very old problem with the code and is likely affecting any rsyslog configuration that is using the "timegenerated" property in their rsyslog templates.

This will also likely need to be fixed in RHEL 7 releases, too.

Comment 2 Tomas Heinrich 2016-03-02 15:07:54 UTC
(In reply to Peter Portante from comment #0)
> Note that this appears to be a very old problem with the code and is likely
> affecting any rsyslog configuration that is using the "timegenerated"
> property in their rsyslog templates.
> 
> This will also likely need to be fixed in RHEL 7 releases, too.

Cloning for el7...

Comment 5 Radovan Sroka 2016-10-03 14:17:22 UTC
Hi Peter,

I was trying to reproduce on rhel6 and I'm not able to do so. From my point of view timestamps are correct.

in rsyslog7 we have state before this commit:
https://github.com/rsyslog/rsyslog/commit/7f6c72a2

So if it is really not working, please give me the reproducer.

Comment 6 Peter Portante 2016-10-10 17:23:31 UTC
The full PR is https://github.com/rsyslog/rsyslog/pull/831, with tests, too.

This only occurs when using the "unixtimestamp" reference, see "date-unixtimestamp" property options.

Comment 7 Tomas Sykora 2016-10-26 09:43:57 UTC
Hi,

this bug does not occur in our version of rsyslog in rhel6 as we are using older version in which the code is different from the current upstream version and works fine. I'm closing this.


Note You need to log in before you can comment on or make changes to this bug.