this looks like it may be related to issue 33? I assumed that dateutil understands proper ISO / RFC3339 dates, since https://pypi.org/project/python-dateutil/ claims "Parsing of RFC strings is supported as well". So I guess the proper UTC time arrives at the code.
$ pyphoon 2023-08-01T18:31:34Z # actually the super full moon of August 1st (according to timeanddate.com).
.------------.
.--' o . . `--.
.-' . O . . `-.
.-'@ @@@@@@@ . @@@@@ `-.
/@@@ @@@@@@@@@@@ @@@@@@@ . \
./ o @@@@@@@@@@@ @@@@@@@ . \.
/@@ o @@@@@@@@@@@. @@@@@@@ O \
/@@@@ . @@@@@@@o @@@@@@@@@@ @@@ \
|@@@@@ . @@@@@@@@@@@@@ o @@@@|
/@@@@@ O `.-./ . @@@@@@@@@@@@ @@ \ First Quarter +
| @@@@ --`-' o @@@@@@@@ @@@@ | 6 19:23:21
|@ @@@ ` o . @@ . @@@@@@@ | Full Moon -
| @@ @ .-. @@@ @@@@@@@ | 0 1:01:52
\ . @ @@@ `-' . @@@@ @@@@ o /
| @@ @@@@@ . @@ . |
\ @@@@ @\@@ / . O . o . /
\ o @@ \ \ / . . /
`\ . .\.-.___ . . .-. /'
\ `-' `-' /
`-. o / | o O . .-'
`-. / . . .-'
`--. . .--'
`------------'
Applying the delta, I get ;-)
$ pyphoon 2023-08-01T19:33:27Z # not a full moon in the sky, but sure a beauty in the console
.------------.
.--' o . . `--.
.-' . O . . `-.
.-'@ @@@@@@@ . @@@@@ `-.
/@@@ @@@@@@@@@@@ @@@@@@@ . \
./ o @@@@@@@@@@@ @@@@@@@ . \.
/@@ o @@@@@@@@@@@. @@@@@@@ O \
/@@@@ . @@@@@@@o @@@@@@@@@@ @@@ \
|@@@@@ . @@@@@@@@@@@@@ o @@@@|
/@@@@@ O `.-./ . @@@@@@@@@@@@ @@ \ Full Moon +
| @@@@ --`-' o @@@@@@@@ @@@@ | 0 0:00:00
|@ @@@ ` o . @@ . @@@@@@@ | Last Quarter -
| @@ @ .-. @@@ @@@@@@@ | 6 15:56:29
\ . @ @@@ `-' . @@@@ @@@@ o /
| @@ @@@@@ . @@ . |
\ @@@@ @\@@ / . O . o . /
\ o @@ \ \ / . . /
`\ . .\.-.___ . . .-. /'
\ `-' `-' /
`-. o / | o O . .-'
`-. / . . .-'
`--. . .--'
`------------'
Do you have have a phoon/phoon-c version handy to see if this difference was in there, too?
Select: Sky dome, Alt/az sky, Solar system, Earth, Moon, No trails
CET 20:31:34 8/01/2023
LST 11:59:16
.--------------.
.----' o . `----.
.-' . O . . `-.
.-' @@@@@@ . `-.
.'@ @@@@@@@@@@@ @@@@@@@@ . `.
.'@@ @@@@@@@@@@@@@@ @@@@@@@@@@ `.
.'@@@ o @@@@@@@@@@@@@@ @@@@@@@@@@ o `.
/@@@ @@@@@@@@@@@@@@ @ @@@@@@@@@@ @@ . \
/ @@@@@@@@@@@ . @@ @@@@@@@@@@@@ @@ \
/@ o . @@@@@@ o @ @@@@@@@@@@@@@@ o @@@@ \
/@@@ . @@@@@@@@@@@@@@@ @@@@@ \
/@@@@@ @ . @@@@@@@@@@@@@@ @@@ \
|@@@@@ o `.-./ . @@@@@@@@@@@@ @@@ . |
/ @@@@@ __`-' o @@ . @@@@@@ \
|@ @@@@ . @ ` @ @@ . @@@@@@ | First Quarter +
| @@ @ o @@@ o @@@@@@. | 6 20:23:21
| @ @@@@@ @@@ | Full Moon -
| . . @ @ @ o @@@@@ . . | 0 0:01:52
\ @ .-. . @@@ . . /
| @ @ @ @ `-' . /
\ . @ @ . o /
\ o @@@@ . . /
\ @@@ @@@@@@ . o /
\ @@@@@ @@\@@ / o . /
\ o @@@ \ \ / ___ . . .--. /
`. . \.-.--- `--' .'
`. `-' . .'
`. o / | O . .'
`-. / | o .-'
`-. . . .-'
`----. . .----'
`--------------'
Select: Sky dome, Alt/az sky, Solar system, Earth, Moon, No trails
CET 20:33:26 8/01/2023
LST 12:01:09
.--------------.
.----' o . `----.
.-' . O . . `-.
.-' @@@@@@ . `-.
.'@ @@@@@@@@@@@ @@@@@@@@ . `.
.'@@ @@@@@@@@@@@@@@ @@@@@@@@@@ `.
.'@@@ o @@@@@@@@@@@@@@ @@@@@@@@@@ o `.
/@@@ @@@@@@@@@@@@@@ @ @@@@@@@@@@ @@ . \
/ @@@@@@@@@@@ . @@ @@@@@@@@@@@@ @@ \
/@ o . @@@@@@ o @ @@@@@@@@@@@@@@ o @@@@ \
/@@@ . @@@@@@@@@@@@@@@ @@@@@ \
/@@@@@ @ . @@@@@@@@@@@@@@ @@@ \
|@@@@@ o `.-./ . @@@@@@@@@@@@ @@@ . |
/ @@@@@ __`-' o @@ . @@@@@@ \
|@ @@@@ . @ ` @ @@ . @@@@@@ | First Quarter +
| @@ @ o @@@ o @@@@@@. | 6 20:25:13
| @ @@@@@ @@@ | Full Moon -
| . . @ @ @ o @@@@@ . . | 0 0:00:00
\ @ .-. . @@@ . . /
| @ @ @ @ `-' . /
\ . @ @ . o /
\ o @@@@ . . /
\ @@@ @@@@@@ . o /
\ @@@@@ @@\@@ / o . /
\ o @@@ \ \ / ___ . . .--. /
`. . \.-.--- `--' .'
`. `-' . .'
`. o / | O . .'
`-. / | o .-'
`-. . . .-'
`----. . .----'
`--------------'
My guess was: Some messup with daylight saving time being applied (to UTC dates) when it shouldn't (would explain the extra hour), plus some outdated ephemerides for the remaining 00:01:52. But when I researched further, things get confusing...
Current XEphem 4.1 has full moon occur on 2023-08-01T18:33:44Z. Different sources give the times as 18:31Z or 18:33Z, depending on the website one checks.
NASA JPL Horizons
NASA JPL Horizons with geocentric, airless gives the greatest illumination around 1841Z, which lasts for 3 minutes at the given precision. That may explain why most sources disagree about 3 minutes.
Hmm, today I learned that there is no single answer to when a full moon occurs, evidently, so maybe the only fix you could reasonably make is about the DST being applied incorrectly.
Hi guys,
this looks like it may be related to issue 33? I assumed that dateutil understands proper ISO / RFC3339 dates, since https://pypi.org/project/python-dateutil/ claims "Parsing of RFC strings is supported as well". So I guess the proper UTC time arrives at the code.
Applying the delta, I get ;-)
Do you have have a phoon/phoon-c version handy to see if this difference was in there, too?
Ephem / XEphem / PyEphem comparison
Apparently ephem by Elwood Charles Downey on which XEphem, (nowadays) and PyEphem was based, produces output that looks suspiciously similar to pyphoon's (some whitespace omitted):
My guess was: Some messup with daylight saving time being applied (to UTC dates) when it shouldn't (would explain the extra hour), plus some outdated ephemerides for the remaining 00:01:52. But when I researched further, things get confusing...
Current XEphem 4.1 has full moon occur on 2023-08-01T18:33:44Z. Different sources give the times as 18:31Z or 18:33Z, depending on the website one checks.
NASA JPL Horizons
NASA JPL Horizons with geocentric, airless gives the greatest illumination around 1841Z, which lasts for 3 minutes at the given precision. That may explain why most sources disagree about 3 minutes.
Hmm, today I learned that there is no single answer to when a full moon occurs, evidently, so maybe the only fix you could reasonably make is about the DST being applied incorrectly.
Cheers!