Getting to following error after latest upgrade for dark sky removal

[kmhutch]

I am getting the following error in my pi clock log:

---

Traceback (most recent call last):
File "PyQtPiClock.py", line 1510, in qtstart
sunset = sun.sunset(dt)
File "PyQtPiClock.py", line 54, in sunset
return suntimes.__timefromdecimalday(self.sunset_t)
File "PyQtPiClock.py", line 67, in __timefromdecimalday
return datetime.time(hour=h, minute=m, second=s)
ValueError: hour must be in 0..23

I did enter my open weather api key and I tested it via my browser.
I tried my config.py, I switched back to example config.py, still fails.
I upgrade the recommend pip mods and it failed the same before and after.
I tried the git reset --hard, reran the update.sh, still fails.

Any ideas?

Kevin

[n0bel]

what is your latitude / longitude (approximately is ok) I need to replicate the issue.

[kmhutch]

lat = 39.359000
long = -104.598000

[n0bel]

Sorry I haven't had time to research this yet. I'll get to it by sunday.

[SerBrynden]

@kmhutch Are those the only errors you see? Which version of Raspberry Pi OS or Raspbian are you using? Also, make sure the tzlocal python package is installed:

sudo pip install --upgrade pip
sudo pip install tzlocal --upgrade

[kmhutch]

Yes the pip is upgraded on my piclock
Yes tzlocal in installed and upgraded, see below:

pi@piclock:~ $ sudo pip install tzlocal --upgrade
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already up-to-date: tzlocal in /usr/local/lib/python2.7/dist-packages (2.1)
Requirement already satisfied, skipping upgrade: pytz in /usr/local/lib/python2.7/dist-packages (from tzlocal) (2018.9)

Here is what I get in the log: tokens removed

pi@piclock:~/PiClock/Clock $ more PyQtPiClock.1.log
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,6,0,0
/166x146?access_token=
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,10,0,
0/166x146?access_token=
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,6,0,0
/388x373?access_token=
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,10,0,
0/388x373?access_token
Traceback (most recent call last):
File "PyQtPiClock.py", line 1510, in qtstart
sunset = sun.sunset(dt)
File "PyQtPiClock.py", line 54, in sunset
return suntimes.__timefromdecimalday(self.sunset_t)
File "PyQtPiClock.py", line 67, in __timefromdecimalday
return datetime.time(hour=h, minute=m, second=s)
ValueError: hour must be in 0..23

FYI I also run the pi with the timezone set to UTC. I use the pi clock in my ham shack for weather and UTC time. Its been set that way since I built years ago.

Kevin H

[SerBrynden]

@kmhutch Ah... the UTC timezone is the problem. Same thing happened to me when I changed to UTC. Let's see what we can do. Standyby.

[BertLindeman]

Looks like the same error I get running the current master with: python PyQtPiClock.py Config-Example
on

        Kernel:         5.10.103-v7+ armv7l
        RPI Firmware:   2021-12-01 15:07
                        version 71bd3109023a0c8575585ba87cbb374d2eeb038f (clean) (release) (start)

Time info from timedatectl

               Local time: Thu 2023-04-06 19:16:57 CEST
           Universal time: Thu 2023-04-06 17:16:57 UTC
                 RTC time: n/a
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

Results in:

Xlib:  extension "RANDR" missing on display "192.168.2.10:0.0".
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,6,0,0/320x293?access_token
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,10,0,0/320x293?access_token
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,6,0,0/746x746?access_token
map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-93.2486732,44.9764016,10,0,0/746x746?access_token
Traceback (most recent call last):
  File "PyQtPiClock.py", line 1510, in qtstart
    sunset = sun.sunset(dt)
  File "PyQtPiClock.py", line 54, in sunset
    return suntimes.__timefromdecimalday(self.sunset_t)
  File "PyQtPiClock.py", line 67, in __timefromdecimalday
    return datetime.time(hour=h, minute=m, second=s)
ValueError: hour must be in 0..23

[BertLindeman]

Same as running the current branch of https://github.com/n0bel/PiClock Python3-SerBrynden
with python3 PyQtPiClock.py Config-Example
Same environment.

Traceback (most recent call last):
  File "PyQtPiClock.py", line 1207, in qtstart
    sunset = sun.sunset(dt)
  File "PyQtPiClock.py", line 53, in sunset
    return SunTimes.__timefromdecimalday(self.sunset_t)
  File "PyQtPiClock.py", line 63, in __timefromdecimalday
    return datetime.time(hour=h, minute=m, second=s)
ValueError: hour must be in 0..23

[BertLindeman]

Last week I did look into the times and dates, but it did not have any success.
If I can help testing, let me know.

[SerBrynden]

@n0bel We might need to install a couple more packages to lookup the timezone from coordinates: timezonefinder and pytz
Below is an example of how this problem might be fixed. Some of the code could be inserted into the suntimes class under __preptime, but I'm not sure where is the ideal place to create the TimezoneFinder() object.

import datetime
import pytz
from timezonefinder import TimezoneFinder

tf = TimezoneFinder()  # object creation

latitude = 39.359000
longitude = -104.598000

tzstr = tf.timezone_at(lng=longitude, lat=latitude)
localzone = pytz.timezone(tzstr)

when_old = datetime.datetime.now()
when_new = when_old.astimezone(tz=localzone)

[n0bel]

@kmhutch Said:

FYI I also run the pi with the timezone set to UTC. I use the pi clock in my ham shack for weather and UTC time. Its been set that way since I built years ago.

The sunrise/sunset code was added in PiClock because not all the weather APIs provided sunrise/sunset (nor moon) information. Darksky of course did provide that information, so older (several years) PiClocks didn't need to calculate sunrise/sunset. They assumed the timezone was the same as the lat/long of course.

The current code is very simplistic in PiClock fails completely when the current timezone does not agree with reasonable sunrise/sunset times (like when sunset is sometime tomorrow instead of today (which can easily happen when you are UTC-6). The DarkSky api simply assumed you wanted a result in the local timezone.

With the newer Weather APIs, this will also affect the forecast days/times as well. The forecast would show UTC days and times. I doubt this is the desired result. We'd actually need two time zones within PiCLock. This is essentially what @SerBrynden is proposing, with one being calculated automatically. However the solution doesn't fix the forecast days/times.

Currently PiClock uses only the timezone set up in the operating system. There is only one timezone.

Since this is a 'clock thing' so to speak I'm thinking what is needed is allow for an optional clock timezone in Config.py. This would only affect the clock (analog clock/digital clock/date at the top). The PiOS would be set to local time, but you could set your clock time to something else.

[n0bel]

@kmhutch Since I can't think of a single use case for an alternate timezone for the clock except for UTC, I implemented a much simpler change. In Config.py I added an optional setting clockUTC

clockUTC = 0 # Clock (analog/digital/top date) to display in UTC regardless of PiOS timezone

If it is missing or zero it is silently ignored. If it is 1, then the clock (analog/digital/top date) will show in UTC.

@kmhutch you'll need to do some things. 1) set your timezone in the operating system to your local timezone. (raspi-config, or gui). 2) update PiClock as normal (git pull). 3) Edit your config to add a line clockUTC = 1

This code is in commit 1ec723c

[kmhutch]

Kevin,
The fix works. Being a Ham, I really depend on it for the radar and time. Lots of thunder storms here.
I tried the the update script, but it did not pull the git changes? I manually added them instead.
Thanks for fixing this this.

73,
Kevin H

ANY Chance of moving PiClock to python 3? Python 2.7 is a pain and it is not supported any more.
I am between projects, so for fun I started converting piclock to 3. I have most of it working on 3 and Qt5. Still a couple of issues with Qt5.

[SerBrynden]

@kmhutch Would you rather see everything in UTC, such as the hourly forecast times and sunrise/set times?

There has been a Python3/PyQt5 version already under https://github.com/n0bel/PiClock/tree/Python3-SerBrynden but it's not quite up-to-date yet. It works with the newer OWM One Cal API 3.0, but not the legacy API 2.5, and it works with Tomorrow.io. But it will still crash if your system time and location are not in the same timezone. I haven't implemented those timezone changes yet, but I've been working on it.

[n0bel]

@kmhutch update.py does not do a git pull. update.py is for after pulling to update/fix any configuration items that need fixing. You would have wanted to do a git pull.

[SerBrynden]

@kmhutch The Python3/PyQt5 version is updated at https://github.com/SerBrynden/PiClock. All dates and times will be shown in the system timezone so everthing is referenced to the same time (so when you look at the time on the clock, you can easily compare it to the time in the forecast or sunrise/set). This fork will also work with older and newer OpenWeather accounts, and Tomorrow.io. I also added timestamps to the log files. Many more changes, but that's what I can think of right now. Once I've had it running with no problems for a few days, I'll put in a pull request to update the branch in n0bel's repo.

73,
KF0JNG