[Bug 280922] Change 46c599340f187db577b9212ab18022f3c7380c68 fixes one case (localtime / gmtime -> strftime('%s'), but breaks another

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 19 Aug 2024 11:28:51 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280922

            Bug ID: 280922
           Summary: Change  46c599340f187db577b9212ab18022f3c7380c68 fixes
                    one case (localtime / gmtime -> strftime('%s'), but
                    breaks another
           Product: Base System
           Version: 14.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: vlad.shabanov@gmail.com
 Attachment #252911 text/plain
         mime type:

Created attachment 252911
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252911&action=edit
example code

Change 46c599340f187db577b9212ab18022f3c7380c68 fixes one case (localtime /
gmtime -> strftime('%s'), but breaks another:

Classic POSIX specification says nothing about tm_zone and tm_gmtoff. A lot of
code assumes, than only described in the specification fields of struct tm
affect to the result of strftime. 

For example, Python has timetuple described in package "time", containing these
fields. The datetime module constructs timetuple to convert the datetime object
to string (see
https://github.com/python/cpython/blob/v3.12.5/Modules/_datetimemodule.c
date_strftime then datetime_timetuple, then
https://github.com/python/cpython/blob/v3.12.5/Modules/timemodule.c )

Change
https://cgit.freebsd.org/src/commit/lib/libc/stdtime?id=46c599340f187db577b9212ab18022f3c7380c68
fixes case discovered by  Dag-Erling Smørgrav but changes the behaviour when
struct tm is constructed manually in assumption, than the structure contains
only standard fields.

IMHO, there is another solution: both localtime and gmtime fill not only
tm->tm_gmtoff, but also tm->tm_zone. Hence, it's possible to distinguish two
cases: 
struct tm filled by library code and struct tm filled manually. 

Yes, I know that strftime('%s') is undocumented feature in Python, but I sure
that this is only one case. I sure that a lot of code assumes than struct tm is
based in local timezone, not UTC.

The example code ant proposed patch solving the issue are attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.