View Issue Details

IDProjectCategoryView StatusLast Update
0000159AlmaLinux-8kernelpublic2021-11-30 12:52
Reporterdwpoon Assigned Toalukoshko  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx86_64 
Summary0000159: Kernel build date is in EST timezone; should be UTC
DescriptionCentOS (and presumably RHEL) has its kernel build timestamp in UTC, whereas AlmaLinux has its kernel build timestamp in EST. This presents a small point of incompatibility.
Steps To Reproduce[[email protected] ~]# uname -a
Linux alma8.example.org 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Mon Nov 15 09:17:08 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
[[email protected] ~]# file /boot/vmlinuz-4.18.0-348.2.1.el8_5.x86_64
/boot/vmlinuz-4.18.0-348.2.1.el8_5.x86_64: Linux kernel x86 boot executable bzImage, version 4.18.0-348.2.1.el8_5.x86_64 ([email protected]) #1 SMP Mon Nov 15 09:17:08 EST, RO-rootFS, swap_dev 0x9, Normal VGA

[[email protected] ~]# uname -a
Linux centos7.example.org 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[[email protected] ~]# file /boot/vmlinuz-3.10.0-1160.15.2.el7.x86_64
/boot/vmlinuz-3.10.0-1160.15.2.el7.x86_64: Linux kernel x86 boot executable bzImage, version 3.10.0-1160.15.2.el7.x86_64 ([email protected], RO-rootFS, swap_dev 0x6, Normal VGA
Additional InformationUTC would be a technically superior choice since it is more universally understood. One place where it makes a difference is when trying to use Python to parse a timestamp. According to https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior :

""""""
strptime() only accepts certain values for %Z:

1. any value in time.tzname for your machine’s locale
2. the hard-coded values UTC and GMT

So someone living in Japan may have JST, UTC, and GMT as valid values, but probably not EST. It will raise ValueError for invalid values.
""""""

Specific example:

[[email protected] ~]# TZ=UTC python3
Python 3.6.8 (default, Nov 9 2021, 16:02:49)
[GCC 8.5.0 20210514 (Red Hat 8.5.0-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.strptime('Mon Nov 15 09:17:08 EST 2021', '%a %b %d %H:%M:%S %Z %Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.6/_strptime.py", line 565, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/usr/lib64/python3.6/_strptime.py", line 362, in _strptime
    (data_string, format))
ValueError: time data 'Mon Nov 15 09:17:08 EST 2021' does not match format '%a %b %d %H:%M:%S %Z %Y'
>>> datetime.strptime('Wed Feb 3 15:06:38 UTC 2021', '%a %b %d %H:%M:%S %Z %Y')
datetime.datetime(2021, 2, 3, 15, 6, 38)
>>>

[[email protected] ~]# TZ=EST python3
Python 3.6.8 (default, Nov 9 2021, 16:02:49)
[GCC 8.5.0 20210514 (Red Hat 8.5.0-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.strptime('Mon Nov 15 09:17:08 EST 2021', '%a %b %d %H:%M:%S %Z %Y')
datetime.datetime(2021, 11, 15, 9, 17, 8)
>>> datetime.strptime('Wed Feb 3 15:06:38 UTC 2021', '%a %b %d %H:%M:%S %Z %Y')
datetime.datetime(2021, 2, 3, 15, 6, 38)
>>>

That is, parsing a UTC timestamp always works, whereas parsing an EST timestamp only works when the Python interpreter is launched in an EST environment.
Tagsalmalinux8
abrt_hash
URL

Activities

toracat

2021-11-26 20:09

reporter   ~0000429

Just noticed that RHEL-8 also shows the time in EST:

$ uname -a
Linux m64r8 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Mon Nov 8 13:30:15 EST 2021 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qi kernel-4.18.0-348.2.1.el8_5 | grep Vendor
Vendor : Red Hat, Inc.

dwpoon

2021-11-30 00:26

reporter   ~0000430

I guess I had been relying on CentOS-specific behavior then! Feel free to close this bug at your discretion.

toracat

2021-11-30 00:38

reporter   ~0000431

On the other hand, in RHEL-7, it shows in UTC:

$ uname -a
Linux m64r7 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 9 16:09:48 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)

alukoshko

2021-11-30 00:53

developer   ~0000432

And aarch64 kernel in RHEL build in EDT timezone.
So no any consistency here.

[[email protected] ~]# uname -a
Linux rhel8 4.18.0-348.el8.aarch64 #1 SMP Mon Oct 4 11:58:32 EDT 2021 aarch64 aarch64 aarch64 GNU/Linux

Issue History

Date Modified Username Field Change
2021-11-25 22:47 dwpoon New Issue
2021-11-25 22:47 dwpoon Tag Attached: almalinux8
2021-11-26 12:24 alukoshko Assigned To => alukoshko
2021-11-26 12:24 alukoshko Status new => confirmed
2021-11-26 20:09 toracat Note Added: 0000429
2021-11-30 00:26 dwpoon Note Added: 0000430
2021-11-30 00:38 toracat Note Added: 0000431
2021-11-30 00:53 alukoshko Note Added: 0000432
2021-11-30 12:52 alukoshko Status confirmed => closed
2021-11-30 12:52 alukoshko Resolution open => fixed