I had added this to be able to use a different icon for thunderstorms,
which were at the time not even being detected as a weather condition
and were just falling back to the default (i.e. no colorization nor
icon). However, the only thunder/lightning unicode icon that is widely
available is too tall, leading to the entire module's text being
vertically-aligned on a different plane from the rest of the modules in
the status bar.
This commit changes the default icon to the same one used for "Rainy"
conditions, while preserving it as a distinct weather type so that
others can still use their own icon if they so choose.
Nothing in imap mail backend reinit the imap connection
when this one is lost, and then the backend always output "socket.error:..."
This change fixes that by cleanup the connection object when
connection is lost so get_connection() will recreate a new one.
This also remove the unless utils.internet() checks already done by
Mail().run()
The win/loss values from the NHL data feed reset in the playoffs, but
don't reflect the current series. Instead, they reflect the current
win/loss total since the beginning of the playoffs.
This commit checks for a key in the API return data indicating that the
game is a playoff game, and if the game is a playoff game the team's
wins will be set to the remainder of the total wins divided by 4 (a team
with 6 overall wins will be assumed to have 2 wins in the current
playoff series).
The team's losses during a playoff series will be set to the amount of
wins for the opposing team.
This properly colorizes when there is a thunderstorm and the weather.com
API response defines the current weather condition as "T-Storm". No idea
why they decide to do this, it's definitely not for brevity as they have
a "Thunderstorms in the Vicinity" weather condition as well. Just a
weird quirk of their API, I guess.
* Fix improper usage of time.tzset()
time.tzname is a tuple containing the non-daylight-savings and
daylight-savings timezone abbreviations. However, when the TZ
environment variable is set to just the daylight-savings timezone (as
the clock module was changed to do in e31c58f), time.tzset() will break
time.tzname by setting both elements of the tuple to that timezone,
causing the effective timezone to fallback to UTC:
>>> time.tzname
('CST', 'CDT')
>>> time.localtime().tm_hour
1
>>> os.environ.putenv('TZ', 'CST')
>>> time.tzset()
>>> time.tzname
('CST', 'CST')
>>> # ^^^ This is broken
...
>>> time.localtime().tm_hour
6
>>> os.environ.putenv('TZ', 'CST+06:00CDT')
>>> time.tzset()
>>> time.tzname
('CST', 'CDT')
>>> time.localtime().tm_hour
1
This fixes this incorrect behavior by building a proper TZ environment
variable to set localtime.
* Use time.timezone instead of time.altzone
* Make _get_local_tz a static method