Page MenuHomeFreeBSD

Kill tz_minuteswest and tz_dsttime.
ClosedPublic

Authored by imp on Mar 11 2019, 9:55 PM.
Tags
None
Referenced Files
F81678929: D19550.id54958.diff
Fri, Apr 19, 7:57 PM
Unknown Object (File)
Wed, Apr 17, 7:43 AM
Unknown Object (File)
Fri, Apr 12, 8:15 PM
Unknown Object (File)
Fri, Mar 29, 2:59 PM
Unknown Object (File)
Mar 8 2024, 2:42 AM
Unknown Object (File)
Mar 8 2024, 2:42 AM
Unknown Object (File)
Mar 8 2024, 2:42 AM
Unknown Object (File)
Mar 8 2024, 2:28 AM
Subscribers

Details

Summary

Research Unix, 7th Edition introduced TIMEZONE and DSTFLAG
compile-time constants in sys/param.h to communicate these values for
the machine. 4.2BSD moved from the compile-time to run-time and
introduced these variables and used for localtime() to return the
right offset from UTC (sometimes referred to as GMT, for this purpose
is the same). 4.4BSD migrated to using the Olsen code/database and
these variables were basically unused.

FreeBSD removed the real need for these with adjkerntz in 1995.
However, some RTC clocks continued to use these variables,
though they were largely unused otherwise. Later, phk centeralized
most of the uses in utc_offset, but left it using both tz_minuteswest
and adjkerntz.

POSIX (IEEE Std 1003.1-2017) states in the gettimeofday specification
"If tzp is not a null pointer, the behavior is unspecified" so there's
no standards reason to retain it anymore. In fact, gettimeofday has
been marked as obsolecent, meaning it could be removed from a future
release of the standard. It is the only interface defined in POSIX
that references these two values. All other references come from the
olson database via tzset().

These were used to more faithfully implement early unix ABIs which
have been removed from FreeBSD. NetBSD has completely eliminated
these variables. Linux has migrated to Olson as well, though these
variables technically still exist for standards conformance. They
appear to always be 0.

So, there's no real reason to have them these days. They are a
historical vestige that's no longer used in any meaningful way.

Remove now useless -d and -t flags in date(1)

These were used to set dst flag and minutes west of UTC
respectively. These are obsolete and have been removed form the
kernel. These existed primarily to faithfully emulate early
Unix ABIs that have been removed from FreeBSD.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 23015
Build 22087: arc lint + arc unit

Event Timeline

I would maybe split kernel commit from date(1) commit? There are some typos in the log message (1995 turned into '\n995' or some such) and both 'Olson' and 'Olsen' are used. Maybe 'tzdata' is a better name for that anyway since I'm not sure if it's still maintained by the one guy vs a group? The last paragraph in the log also seems redundant, though if this is two commits squashed together in a single review and you plan to split the messages back out again that is probably ok. If so, it might have been simpler to just create two reviews (arc --head can help with this if they are separate git commits) and chain them in a stack.

brooks added a subscriber: brooks.

Looks good to me.

sys/amd64/linux32/linux32_machdep.c
667

It's slightly tempting to make this a const struct initialized to {0, 0}.

This revision is now accepted and ready to land.Mar 11 2019, 10:12 PM
In D19550#418301, @jhb wrote:

I would maybe split kernel commit from date(1) commit?

Yes, that's how I'll split them. phab doesn't show that I've already done that.

There are some typos in the log message (1995 turned into '\n995' or some such) and both 'Olson' and 'Olsen' are used. Maybe 'tzdata' is a better name for that anyway since I'm not sure if it's still maintained by the one guy vs a group? The last paragraph in the log also seems redundant, though if this is two commits squashed together in a single review and you plan to split the messages back out again that is probably ok. If so, it might have been simpler to just create two reviews (arc --head can help with this if they are separate git commits) and chain them in a stack.

Today, it's almost never simpler to create two reviews for something this small. It's needless friction until we have a arc --separate or something that does all that for me.

I'll fix thee olson vs olsen vs tzdata in the commit message.

Huh, I create separate reviews fairly often using 'arc --head <hash of last commit> <hash of prev commit>'. It's what I did for D19480, D19482, and D19483 which all came out of a single git branch. I just have git log in a second window to make it easy to copy and paste the hashes. I do wish you could push a patch series directly, but then when you add fixups for review feedback on one of the patches you'd probably need to resort to using 'arc --head' when it came time to update an individual patch.

This revision was automatically updated to reflect the committed changes.