Bug 1328832

Summary:	at shows incorrect time when the UTC timezone is specified
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Mraz <tmraz>
Component:	at	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Radka Brychtova <rskvaril>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4	CC:	ffotorel, jscotka, lmiksik, qe-baseos-daemons, rskvaril, stuart.j.newman
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	at-3.1.13-21.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1320322	Environment:
Last Closed:	2016-11-04 03:30:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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