WEEWXtags.php astronomy dates not quite right

[ktrue]

Looking at the values for season and lunar cycle dates compared to Weather-Display shows the format from pyephem uses a date/time format that is 'H:M UTC dd MON YYYY' when 'H:M UTC MON dd YYYY' is the WD expected format.
It's not causing a problem with the template so far, it's just not matching the expected WD date format for the fields:

Variable       Weather-Display              WEEWXtags
$marchequinox  09:38 UTC March 20 2021      15:33 UTC 20 March 2022   
$junesolstice  03:33 UTC June 21 2021       03:32 UTC 21 June 2021 
$sepequinox    19:22 UTC September 22 2021  19:21 UTC 22 September 2021 
$decsolstice   16:00 UTC December 21 2021   15:59 UTC 21 December 2021
$moonperihel   17:15 UTC January 3 2022     01:15 UTC 4 January 2022
$moonaphel     02:08 UTC July 5 2021        02:31 UTC 6 July 2021
$moonperigee   15:21 UTC April 27 2021      15:25 UTC 27 April 2021
$moonapogee    21:54 UTC May 11 2021        21:54 UTC 11 May 2021
$newmoon       02:31 UTC April 12 2021      02:30 UTC 12 April 2021
$nextnewmoon   19:01 UTC May 11 2021        18:59 UTC 11 May 2021
$firstquarter  07:00 UTC April 20 2021      19:12 UTC 19 May 2021
$lastquarter   19:51 UTC May 3 2021         19:50 UTC 3 May 2021
$fullmoon      03:32 UTC April 27 2021      03:31 UTC 27 April 2021
$fullmoondate  April 27 2021                27 Apr 2021

The $firstquarter for WeeWX shows the next first quarter, while the WD value is for the current month first quarter, but that's not a problem. The times are within one minute, so that's quite good.

For the Moon status:

Variable       Weather-Display                          WEEWXtags
$moonage       Moon age: 9 days,0 hours,28 minutes,67%  Moon age: 10 days,20 hours,24 minutes,67%
$moonphase     67%                                      67%  
$moonphasename Waxing Gibbous Moon                      Waxing gibbous

The 'age' seems a bit off, but the percent full and phase names do match.

[gjr80]

Can easily change the 'astronomy' date-time string format. Just to clarify one thing, does the format need to have month before day to parse correctly or is $SITE['WDdateMDY'] used to determine the month/day order before parsing?

[gjr80]

The 'age' seems a bit off, but the percent full and phase names do match.

Will need dig into this a bit further, I suspect there may be a GMT/local time issue coming in here but on first glance that does not seem to account for 44 hours difference. Since $moonphase agrees I am fairly confident this is something in WeeWX-Saratoga and not an underlying WeeWX issue.

[gjr80]

Philosophical question re moon phase date-times. Appreciate what WD does, but should we be providing the next phases or the current month phases? Would seem to me that if it was say the 29th of the month your sun/moon page may well be showing three or four moon phases that have been and gone whereas I would expect the average user would want to know the upcoming phases?

[ktrue]

For the either the 'dd MON YYYY' or 'MON dd YYYY' format in the astronomy dates, it doesn't pay attention to the $SITE['WDdateMDY'] in processing. That setting is only used to parse dd/mm/yyyy or mm/dd/yyyy format dates. The heavy lifting is done by PHP strtotime() function which is fed the value after moving the 'HH:MM UTC' to the end of the date string. strtotime() generously accepts either version (that's why the dates are parsed correctly in both WD and WeeWX current version.

You're likely correct that some of the dates may, in fact, be local times but marked as UTC. Those need to be in UTC time.

I don't know what WD's algorithm is for the moon phase date-times to display. It seems reasonable to post the next time for a phase when that phase date has passed this month. So leaving them as upcoming phases after this-month's phase has passed seems reasonable to me.

[gjr80]

The 'age' seems a bit off, but the percent full and phase names do match.

Will need dig into this a bit further, I suspect there may be a GMT/local time issue coming in here but on first glance that does not seem to account for 44 hours difference. Since $moonphase agrees I am fairly confident this is something in WeeWX-Saratoga and not an underlying WeeWX issue.

I've been looking at this a bit more and I am not entirely convinced the WeeWX/WeeWX-Saratoga is wrong and WD is right. As I write this it is just after 2200h here on 22 April (ie 1200GMT, 0500 your time 22 April) and the moon is 72.6%. When I look at my WEEWXtags.php it reports moon age 73% and when I look at your WD produced testtags.php it says moon age 73%. Agreement. The lunar cycle is 29.53 days in length and we are approaching full moon so we are 0.726 * (29.53/2) = 10.7 days into the lunar cycle. WEEWXtags.php says 10 days, 9 hours, 34 minutes (10.4 days) but your testtags.php says 9 days,13 hours,57 minutes (9.58 days). I looked at testtags.php on a few WD based sites around the globe and they all show 9 days,13 hours,57 minutes so the discrepancy is not due to timezone. If you round 72.6% to 73% you get 10.8 hours so that does not account for the discrepancy either.

WEEWXtags.php is approximately 7 hours off which seems too much for me, pyephem is far more accurate than that.

Still looking into why WEEWXtags.php is off but I am not so confident that WD should be used as the benchmark for this tag.

[ktrue]

Unfortunately, the authoritative source for the astronomical data (US Naval Observatory) has taken down their ability to query moon (and other celestial info) from their website, so the gold-standard for that data is not currently available.

A while back, when the USNO was getting flakey about access, I went on a quest for PHP/JavaScripts that could provide reasonable data via calculations. I finally settled on the set of scripts included in my get-USNO-sunmoon.php script which closely matched the output obtained via API to aa.usno.navy.mil website. I also wrote a tool to compare the various weather software outputs for sun/moon info (runs on a localhost). Here's a comparison with WeeWX added to the list.

[gjr80]

Thanks. As usual I am making this far more complex than it need be. I think there is (essentially) agreement on everything except for moon age. But it’s quite simple to work out moon age, it’s just the elapsed time since the last new moon. Both WeeWX and WD agree the last new moon was 0230 12 April GMT. As I write it’s 2100 22 April GMT, so moon age is 10 days 18 hours 30 minutes. Looking at testtags.php I see 9 days 23 hours 15 minutes. WEEWXtags.php shows 11 days 18 hours 29 minutes. Based on WEEWXtags.php being exactly 24 hours out that suggests a simple (but perhaps not so obvious arithmetic error).

[gjr80]

Found the WEEWXtags.php.tmpl moon age bug; it seems there is a difference between int() and round()! For some reason I was rounding a decimal number of days before taking the integer number of days and of course if you had more than half a day it was rounded up. No idea why I had that (it's a WeeWX-WD hangover from years ago) when it is clearly wrong.

Fixed at commit aa6e65e589e7fe0089099320ee793e075ac3f3a7.

Now for the others.

[gjr80]

Now have $newmoon, $firstquarter, $fullmoon and $lastquarter populated with the previous phase and the next three phases. That appears to be what WD does, and if I would have looked that is what I have on my modified dashboard. I believe the Sun/Moon page displays these in ascending time order left to right so I hope that comes out OK. Just need to test the code when I am home again.

Had another look at the UTC date-time formats. I was going to try to be a bit clever (and cut down on places where the user need to change settings/formats) and derive d/m or m/d order set by the user for date formats in WEEWXtags.php (under [StdReport] [[WEEWXtagsReport]]), but on second thoughts I think that might be courting trouble. Tom (Keffer) keeps telling me unnecessary complexity is bad and the Zen of Python says 'Simple is better than complex'. So since you said the UTC date formats are working as is, I will leave them as is. Though $fullmoondate format is bugging me so I will fix that one.