Localized day-of-week in forecasts may be fragile

[dgw]

Had a report (and simplified test code demonstrating so) that localizing the day of week as below doesn't always work properly (also applies to pirateweather):

sopel-weather/sopel_modules/weather/providers/weather/openmeteo.py

Line 69 in 3506e90

'dow': datetime.fromtimestamp(data['time'][day]).strftime('%A'),

On systems set to UTC, this seems to result in forecasts showing days off by one, e.g. M-Th when requested on Tu (expecting Tu-F in output).

Test code:

import requests
from datetime import datetime

r1 = requests.get("https://api.open-meteo.com/v1/forecast?latitude=39.296828&longitude=-76.614008&daily=temperature_2m_min,temperature_2m_max,weathercode&timeformat=unixtime&timezone=auto")
d1 = r1.json()
d1 = d1['daily']
print("auto")
for day in range(4):
    print(datetime.fromtimestamp(d1['time'][day]).strftime('%A'))

r2 = requests.get("https://api.open-meteo.com/v1/forecast?latitude=39.296828&longitude=-76.614008&daily=temperature_2m_min,temperature_2m_max,weathercode&timeformat=unixtime&timezone=America/Chicago")
d2 = r2.json()
d2 = d2['daily']
print("")
print("America/Chicago")
for day in range(4):
    print(datetime.fromtimestamp(d2['time'][day]).strftime('%A'))

Output on a system set to 'Etc/UTC':

auto
Monday
Tuesday
Wednesday
Thursday

America/Chicago
Tuesday
Wednesday
Thursday
Friday

I got the same output in Termux on an Android phone, but haven't tested on a "real computer" yet.

A timezone should likely be passed to datetime.fromtimestamp—presumably UTC, since AFAIK a Unix timestamp should always be in UTC—and then the value localized to the timezone at the coordinates.