Bug 1328832 - at shows incorrect time when the UTC timezone is specified
Summary: at shows incorrect time when the UTC timezone is specified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: at
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Radka Brychtova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-20 11:38 UTC by Tomas Mraz
Modified: 2019-12-16 05:41 UTC (History)
6 users (show)

Fixed In Version: at-3.1.13-21.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1320322
Environment:
Last Closed: 2016-11-04 03:30:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2311 0 normal SHIPPED_LIVE at bug fix update 2016-11-03 13:41:26 UTC

Description Tomas Mraz 2016-04-20 11:38:43 UTC
+++ This bug was initially created as a clone of Bug #1320322 +++

Description of problem:
at shows incorrect time when the UTC timezone is specified

Version-Release number of selected component (if applicable):
at-3.1.10-48.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
- Timezone UTC:

--------------------
# date
Tue Mar 22 18:41:08 UTC 2016
--------------------

- at command with UTC option:

--------------------
# at 17:00 UTC
at> logger TEST
at> <EOT>
job 1 at 2016-03-23 16:00
--------------------

Actual results:

--------------------
# at 17:00 UTC
at> logger TEST
at> <EOT>
job 1 at 2016-03-23 16:00
--------------------

Expected results:

--------------------
# at 17:00 UTC
at> logger TEST
at> <EOT>
job 1 at 2016-03-23 17:00
--------------------

Additional info:

"parsetime.y" is substracting 3600 when UTC is indicated in the command (isgmt).

--- Additional comment from Stuart Newman on 2016-03-25 15:52:19 CET ---

The problem is caused by code in the parsetime subprogram in parsetime.y . exectm is moved to currtm after exectm.tm_isdst is set to -1. Nothing ever resets currtm.tm_isdst to either 0 or 1. When execution reaches line 508, currtm.tm_isdst is still -1, causing the test to pass, reducing the scheduled time by one hour. The proposed fix moves exectm to currtm before exectm.tm_isdst is set to -1.

The proposed fix (based on line numbers in at-3.1.10-48.el6.i686 is 

479a480
 > memcpy(&currtm,&exectm,sizeof(currtm)); 
482d482 
< memcpy(&currtm,&exectm,sizeof(currtm));

--- Additional comment from Tomas Mraz on 2016-03-29 11:07:14 CEST ---

The proper fix is different. It is currently included in the Fedora rawhide package.

Please also open RHEL-7.3 bug so there is no regression.

Comment 2 Stuart Newman 2016-04-20 15:43:17 UTC
what about a version for rhel 6?

Comment 3 Tomas Mraz 2016-04-20 15:47:17 UTC
Unfortunately it will have to wait for the next RHEL-6 update release.

Comment 5 Radka Brychtova 2016-04-29 12:03:55 UTC
The automatic test passed with the new package on all arch => verified

Old package : 

:: [   LOG    ] :: Package versions:
:: [   LOG    ] ::   at-3.1.13-20.el7.ppc64
....

:: [   PASS   ] :: Command 'date' (Expected 0, got 0)
:: [   PASS   ] :: Add event for the time without UTC (Expected 0, got 0)
:: [   PASS   ] :: File '/var/tmp/tmp.GFmDnMJ7QG' should contain '12:43' 
:: [   PASS   ] :: Add event for time vith UTC (Expected 0, got 0)
:: [   FAIL   ] :: File '/var/tmp/tmp.5sRmgo0tTi' should contain '12:43' 


New package 
:: [   LOG    ] :: Package versions:
:: [   LOG    ] ::   at-3.1.13-21.el7.ppc64
....

:: [   PASS   ] :: Command 'date' (Expected 0, got 0)
:: [   PASS   ] :: Add event for the time withou UTC (Expected 0, got 0)
:: [   PASS   ] :: File '/var/tmp/tmp.2bYK08hG62' should contain '17:08' 
:: [   PASS   ] :: Add event for time vith UTC (Expected 0, got 0)
:: [   PASS   ] :: File '/var/tmp/tmp.BHVLk9EDbm' should contain '17:08'

Comment 7 errata-xmlrpc 2016-11-04 03:30:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2311.html


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