Some details here:
https://bugs.chromium.org/p/chromium/issues/detail?id=723943#c17
Other details,
util-linux change points out that this _might_ change again.
while current hwclock output is close to RFC #822 format it fails section 5.1
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
As evidence from,
localhost local # /sbin/hwclock -v
hwclock from util-linux 2.28.2
localhost local # /sbin/hwclock -r
2017-06-15 16:09:01.181684+8:00
where instead of '+0800' for tz its '+8:00'
So ideally we could take the hwclock output directly into python's time module as like
t2 = '2017-06-15 06:09:43.796446-0800'
tv2 = time.strptime(t2, "%Y-%m-%d %H:%M:%S.%f%z")
This will require likely updating that module in python though as our current version (2.7?) returns the following failure,
ValueError: 'z' is a bad directive in format '%Y-%m-%d %H:%M:%S.%f%z'
despite 'man strftime' saying,
%z The +hhmm or -hhmm numeric timezone (that is, the hour and minute offset from UTC). (SU)
Additionally we may still need to either,
- pull another version of util-linux if its chosen to match RFC 822 or suggest / upstream that change
- just regreplace : and zero extend the hour
One last possibility is to examine other python modules like 'arrow' which may offer more flexibility for parsing date strings in general
Comment 1 by sheriffbot@chromium.org
, Jun 18 2018Status: Untriaged (was: Available)