View Issue Details

IDProjectCategoryView StatusLast Update
0000159AlmaLinux-8kernelpublic2021-11-26 20:12
Reporterdwpoon Assigned Toalukoshko  
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
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.

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