Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

CVS commit: src/lib/libc/time



Module Name:    src
Committed By:   christos
Date:           Thu Jan 23 22:44:22 UTC 2025

Modified Files:
        src/lib/libc/time: Makefile NEWS asctime.c ctime.3 localtime.c
            private.h strftime.3 strftime.c theory.html tz-link.html tzfile.5
            tzselect.8 version zdump.8 zdump.c zic.8 zic.c

Log Message:
update to 2025a

  Changes to code

    strftime %s now generates the correct numeric string even when the
    represented number does not fit into time_t.  This is better than
    generating the numeric equivalent of (time_t) -1, as strftime did
    in TZDB releases 96a (when %s was introduced) through 2020a and in
    releases 2022b through 2024b.  It is also better than failing and
    returning 0, as strftime did in releases 2020b through 2022a.

    strftime now outputs an invalid conversion specifier as-is,
    instead of eliding the leading '%', which confused debugging.

    An invalid TZ now generates the time zone abbreviation "-00", not
    "UTC", to help the user see that an error has occurred.  (Thanks
    to Arthur David Olson for suggesting a "wrong result".)

    mktime and timeoff no longer incorrectly fail merely because a
    struct tm component near INT_MIN or INT_MAX overflows when a
    lower-order component carries into it.

    TZNAME_MAXIMUM, the maximum number of bytes in a proleptic TZ
    string's time zone abbreviation, now defaults to 254 not 255.
    This helps reduce the size of internal state from 25480 to 21384
    on common platforms.  This change should not be a problem, as
    nobody uses such long "abbreviations" and the longstanding tzcode
    maximum was 16 until release 2023a.  For those who prefer no
    arbitrary limits, you can now specify TZNAME_MAXIMUM values up to
    PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently
    misbehaved unless TZNAME_MAXIMUM was less than INT_MAX.

    tzset and related functions no longer leak a file descriptor if
    another thread forks or execs at about the same time and if the
    platform has O_CLOFORK and O_CLOEXEC respectively.  Also, the
    functions no longer let a TZif file become a controlling terminal.

    'zdump -' now reads TZif data from /dev/stdin.
    (From a question by Arthur David Olson.)


To generate a diff of this commit:
cvs rdiff -u -r1.58 -r1.59 src/lib/libc/time/Makefile
cvs rdiff -u -r1.45 -r1.46 src/lib/libc/time/NEWS
cvs rdiff -u -r1.31 -r1.32 src/lib/libc/time/asctime.c
cvs rdiff -u -r1.71 -r1.72 src/lib/libc/time/ctime.3
cvs rdiff -u -r1.144 -r1.145 src/lib/libc/time/localtime.c
cvs rdiff -u -r1.70 -r1.71 src/lib/libc/time/private.h
cvs rdiff -u -r1.37 -r1.38 src/lib/libc/time/strftime.3
cvs rdiff -u -r1.56 -r1.57 src/lib/libc/time/strftime.c
cvs rdiff -u -r1.20 -r1.21 src/lib/libc/time/theory.html
cvs rdiff -u -r1.17 -r1.18 src/lib/libc/time/tz-link.html
cvs rdiff -u -r1.36 -r1.37 src/lib/libc/time/tzfile.5
cvs rdiff -u -r1.14 -r1.15 src/lib/libc/time/tzselect.8
cvs rdiff -u -r1.26 -r1.27 src/lib/libc/time/version
cvs rdiff -u -r1.25 -r1.26 src/lib/libc/time/zdump.8
cvs rdiff -u -r1.64 -r1.65 src/lib/libc/time/zdump.c
cvs rdiff -u -r1.51 -r1.52 src/lib/libc/time/zic.8
cvs rdiff -u -r1.93 -r1.94 src/lib/libc/time/zic.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Home | Main Index | Thread Index | Old Index