Refresh correlation data Clean up the overrides.conf a bit and regenerate correlations now that the NWS has retired some WX weather zones. This addresses some incorrect correlations to now dead forecasts in the Los Angeles area (thanks to Chime Hart for reporting), as well as likely others.
Prepare for 2.4.3 release Switch to the 2022 US Census Bureau data, March 2023 NWS WX zones, latest OurAirports open data set, and refreshed active forecast and station lists. Regenerate all correlation sets based on these updated sources.
Don't use U mode, removed in python3.11 This patch was helpfully submitted by Bas Couwenberg to drop use of the universal newline flag, since Python 3.11 no longer supports it. It probably breaks the ability to build new correlation files under Python 2.7 and earlier, but since it shouldn't affect operation of the utility with prebuilt correlations (the way it's typically used), this isn't yet considered to drop Python 2.7 support altogether.
Refresh correlation data A new correlation data build, based on more recent active WX zones (notably, the Los Angeles California area was re-zones earlier this year).
Force UTF-8 locale when reading configs and data Apparently, Python on Windows defaults to assuming CP1252 encoding unless otherwise specified, as opposed to the UTF-8 assumption made on POSIX platforms. Since our configuration and data files are expected to always use UTF-8 encoding, be clear in the ConfigParser.read() calls about that. We only do this under Python 3.x, as that method doesn't have an encoding parameter in 2.7. Thanks to Lance Bermudez for reporting this.
Refresh correlation data and update copyright year Just a basic correlation update based on more recent active METAR station and WX zone lists. Also update the copyright year for files which have been edited so far in 2021 as well as in the LICENSE file.
Correct handling of boolean selections The selections proxy class, which mashes together command-line arguments and configuration options, contained a longstanding and fatal flaw with its handling of boolean values. In particular, falsey values were consistently treated as truthy due to naively recasting str to bool (which will always yield True unless empty). This went unnoticed for so long because the majority of these settings default to False, meaning the only reason most users had to set them was to override them to True. Many thanks to Jordan Russell for bringing this bug to my attention, and for supplying an initial patch on which this fix is heavily based. Co-Authored-By: Jordan Russell
Refresh active station list and correlation data Perform a fresh build of data sets from current sources, and add a few additional overrides for previously unknown stations. Also update from 2019 to 2021 US Census data, from March 2020 to September 2021 CountyZone maps, and from 2020-08-29 to 2021-08-29 airport IDs and active METAR stations/WX zones.
Correct and simplify URLError exception handling Julien Palard pointed out that the way URLError exceptions were being manually cobbled into the stderr stream wasn't quite working (thanks!), but it was also unnecessarily complicated for reasons I don't recall now. Rip most of it out and just go with a basic catch/error/re-raise there instead.
Refresh active station list and correlation data Perform a fresh build of data sets from current sources, and add a few additional overrides for previously unknown stations.
Correct default_atypes to match what's generated Kevin Monceaux reported a regression with the 2.4 release. Running with the -a/--alert option and no limited --atypes or atypes override in weatherrc resulted in a message about undefined URLs and no normal output. This problem crept in when hard-coding alert types in the correlator after ditching the woefully unmaintained zonecatalog.curr.tar data source (commit 8a37edd). Update default_atypes so that it covers all relevant non-forecast URLs the correlate routine embeds.
Make the build reproducible While auditing Debian's packages, Chris Lamb reported[*] that weather-util's correlation set generation is not reproducible because it embeds timestamps without a means to override them and also varies by system timezone. Allow SOURCE_DATE_EPOCH from the calling environment and assume UTC rather than relying on locale settings when no timezones are specified. [*] https://bugs.debian.org/964721