WXforum.net
Web Weather => Weather Website PHP/AJAX scripting => Custom Website Templates => Topic started by: gwwilk on June 20, 2013, 11:03:52 AM
-
I've been up to no good again. :-)
These scripts display the NWS Climate Prediction Center's Near-Term (1 week to 3 month) and Long-Term (1 month to 13 month) temperature and precipitation outlook maps. You can see them here, starting with Long-Term (http://www.gwwilkins.org/wxcpcltoutlook.php). The scripts each contain links to the other.
There are two settings. The first is $divWidth, the width of the <div> where the maps are displayed. It's currently set at 656px which works for a Saratoga template page with style="border:inset", the default for these scripts. The second setting switches onmouseover and onclick map display behavior. To use 'onmouseover' behavior set $mouseOver=true, and to use 'onclick' behavior set $mouseOver=false.
The long term outlook maps are updated at about 8:30 AM on the third Thursday of the month. The code to update the month arrays to begin with the next month is set to occur at 8:30 AM on the third Thursday each month, which could be anywhere from the 15th to the 20th. The script rotated correctly to the current map dates at 8;30 this morning, so I believe the code works as intended. Please let me know via the forum if you encounter errors in the month array display algorithms.
Edit: A stray, unused 'onClick' thwarted validation in wxcpcoutlook.php. This has been corrected in the present zip.
Edit 29 June 2013: There was a problem with the scripts interfering with the ajaxgizmo's function. This has been fixed in wxcpcoutlook2.zip
Edit 30 June 2013: Google Analytics users will find that the switch '$mouseOver' doesn't work. The wxcpcoutlook3.zip files use a work-around that hard-codes the 'mouseover' or 'onclick' functionality. If you need them, the additional files are labeled '...-ga-mo' for 'mouseover' and '...-ga-oc' for 'onclick'.
Edit 30 June 2013a: Version 3a corrects the internal links for the ...-ga-... files that pointed back to the original files pair rather than the new ones. It also hopefully kills the last of the missing 'px' entries.
Edit 14 July 2013: Version 3b removes ill-advised ' c;' spaces from the scripts. These prevented menu line-breaks from occuring at logical places.
Edit2 14 July 2013: Version 4 revises the logic that determines when to switch the maps to NWS creation during the current month rather than the previous month. This version replaces all prior versions due to the flawed date-switching logic in those scripts that switched months prematurely during the third week on Sun-Wed. Please discard the previous versions and use this one.
Edit3 14 July 2013: Version 5 corrects problems with boundary conditions around a new year where the long-term outlook scripts would have failed. I would again strongly suggest that you replace any older version(s) with version 5.
Edit 15 July 2013: Version 5a adds an option, $allWhiteBox, to the near-term scripts to use all white 'white_box.png' backgrounds rather than switching to shades of gray for the black and silver themes. Switching to shades of gray may be overkill and is beset by browser cache issues if viewers switch themes back and forth. Just set $allWhiteBox = true to use all white box
backgrounds. The white box was originally created to maintain the same aspect ratio of the US when switching maps. Without it the vertical compression/expansion of the US during switching is very distracting.
Edit 18 July 2013: Version 5b further revises the logic that determines when to switch maps by relying on a day-of-month of the third Thursday of the month calculation rather than day of week calculations. While the prior algorithm worked this month, it would fall over some months. The new algorithm should solve this problem.
Edit2 18 July 2013: I inadvertently deleted a variable from Version 5b. Version 5c restores it and has been verified to change maps at 7:30am US/Eastern on the third Thursday (this month anyway). Please remove all prior versions and use this one for the wxcpcltoutlook scripts. The wxcpcoutlook scripts are unchanged from 7/14/2013.
Edit 21 Feb 2014: The script displayed erroneous dates in some of the links this month. There were also problems in Nov and Dec that I uncovered while debugging the script. All of the charts displayed correctly, but the links didn't match the chart dates at times. Version 6 hopefully fixes those problems. I've also updated the fixed mouseover and fixed onclick scripts for Google Analytics compatibility.
Edit 23 June 2015: The NWS CPC has moved the long-term outlook from experimental to production. The old Version 6 no longer displays updated maps and has been removed. Version 7 displays the 'Official' production CPC long-term outlook charts.
Edit2 23 June 2015: I had completely forgotten what the alternate versions were all about in my haste to publish the click-mouseover configurable version that I use. They indeed needed modification before they could function properly again. Version 7a supplants Version 7 and contains updated Google Analytics compatible onclick-onmouseover scripts.
Edit 18 Jan 2020: Zip removed from this thread. It's now available as 'wxcpcoutlook.zip' on my scripts page (https://www.gwwilkins.org/gwwScripts.php). See my new post in this thread as to why the script needed modification.
-
A++ Jerry!!
-
Thanks, Tony! You might download the corrected zip just so the pages both validate. :oops:
-
Thanks Jerry. I have added it, and while the NWS CPC is primarily USA it does show enough for my area of Southern Ontario.
Paul
-
Thanks Jerry. Another great script. Appreciate your time and effort.
:grin:
MikeyM
-
Hey A++ man awesome job!
-
Very nice, Jerry - as usual. However, I have two problems (expected this, didn't you?), each on both scripts and no changes made to the scripts.
Mouseover doesn't work - have to click (both are set to true).
Gizmo is not updating completely. Updates show up, but are not green when new data is loaded. Also, update retains 24-hour time format, which means AJAX has not finished its job. Only on these two pages.
Weird, eh?
Thank you.
-
Very nice, Jerry - as usual. However, I have two problems (expected this, didn't you?), each on both scripts and no changes made to the scripts.
Mouseover doesn't work - have to click (both are set to true).
Gizmo is not updating completely. Updates show up, but are not green when new data is loaded. Also, update retains 24-hour time format, which means AJAX has not finished its job. Only on these two pages.
Weird, eh?
Thank you.
I can think of a couple of possibilities, either a namespace conflict or a server PHP version problem. I can try to solve the former problem, but I don't know enough about PHP versions to help with the latter. The attached test php contains multiple renamed php and javascript entities to see if that makes any difference--I suspect it won't. Just upload it to your server and view it with your browser, 'wxcpcltoutlook-test.php', to see if it makes any difference.
The issue with the ajaxGizmo is interesting. I notice the same behavior on my site. Somehow the ajax updates aren't occuring here. I don't see where the problem is after checking the many files involved there. Maybe I can get at it later.
One interesting difference between your site and mine is your use of google analytics which inserts its javascript modifications to your home page before the page has been completed. This probably isn't the problem either, but you might try disabling google analytics just to be sure.
Your reputation as a bug-finder is intact, John :-)
-
OK - 'what the heck?' time...
PHP is v5.3.25.
Ran the test script exactly as received. Gizmo still fails, but mouseover is (was) working.
Added my analytics call at the same location ALL of my other scripts have it (Google recommended loc, if I remember correctly). Mouseover stopped working. Removed call - mouseover still failing. Cleared cache (which is set at zero anyway), tried a different browser - still fails.
Went back to a fresh copy of the script - mouseover working again. Removed the last script line (blank line) so the script actually ended after the last ?>. Mouseover failed. Bottom line - no matter what change is made to the script, even when it is restored the mouseover continues to fail.
And, all along, no matter what was done to the script the gizmo still does not complete loading.
](*,)
-
Remember that one error message causes the JavaScript engine to stop processing all scripts on a page .. check the JavaScript error log and see if something is mentioned there -- on Firefox, it's the series of checkmarks/Xs at the upper-right screen just above the actual page that opens the console.
If no errors are shown, and you have a lot of JavaScripts, it may be that one of the add-on scripts is executing too rapidly so the events needed for the AJAX fetch/format/display don't complete. With JavaScript, it's generally best to have as little as possible on the page so the site runs well in the browser (even on older systems with limited resources).
Just some musings about possible causes of the problem.
-
Remember that one error message causes the JavaScript engine to stop processing all scripts on a page .. check the JavaScript error log and see if something is mentioned there -- on Firefox, it's the series of checkmarks/Xs at the upper-right screen just above the actual page that opens the console.
Ken, the only error showing was to two css statements that were missing a 'px' after a height directive. Lines 140 and 164 in the test script. Also the path to the CSS file in line 44 is incorrect for my system. Corrected both, but still fails.
If no errors are shown, and you have a lot of JavaScripts, it may be that one of the add-on scripts is executing too rapidly so the events needed for the AJAX fetch/format/display don't complete. With JavaScript, it's generally best to have as little as possible on the page so the site runs well in the browser (even on older systems with limited resources).
My analytics call is still omitted, so it's down to just what Jerry sent. Interesting that the gizmo is also failing for Jerry.
Just some musings about possible causes of the problem.
Please - step in at any time. Most appreciated as always. The test script is still on the server if you'd care to poke around. :-)
-
I've been scratching my head here as well, John & Ken.
I've tried both Firefox's and Chrome developer's tools. Firefox found a couple of possible tiny code problems of no consequence, and Chrome's developer tools have been happy all along, i.e. no JS errors reported on the developer's console.
That leaves much more subtle possible problems with the code such as JS autoinsertion of semicolons and JS namespace conflicts. I found several places in my wxcpcltoutlook.php and wxcpcoutlook.php scripts where the JS functions weren't terminated with semicolons. This is OK unless the next statement begins with [, (, +, -, or / which didn't seem to be the case either here or in ajaxgizmo.js. Since all JS variables declared outside of functions are globals, this opens a wide door for namespace conflicts. I've tried renaming ajaxgizmo.js's most obvious potential conflicts such as 'ie4, 'ie8', and 'browser' using leading and trailing underscores, but to no avail. I also terminated all of ajaxgizmo's functions with semicolons and added an initial semicolon before the first statement--didn't help either.
Am I correct, John, in that you get a mouseover when first loading the wxcpcltoutlook-test.php script but then it goes away and doesn't return with subsequent restoration of the script to original? That's probably a result of server caching, which IMHO doesn't always clear with a browser refresh. Sometimes several refreshes are needed to see the effects of otherwise stable supporting script changes. That phenomenon can quickly flatten one's forehead.
I'll keep poking around.
-
Am I correct, John, in that you get a mouseover when first loading the wxcpcltoutlook-test.php script but then it goes away and doesn't return with subsequent restoration of the script to original? That's probably a result of server caching, which IMHO doesn't always clear with a browser refresh. Sometimes several refreshes are needed to see the effects of otherwise stable supporting script changes. That phenomenon can quickly flatten one's forehead.
That is correct, Jerry. However, in addition to a 0MB cache as mentioned (and doing multiple clears), I also tried different browsers which had not seen this page so there was no chance to cache it with those.
Forehead a little flatter now...? ](*,)
Hit 118° a little while ago making a new official record for the day. Maybe it's the heat... :roll:
-
Am I correct, John, in that you get a mouseover when first loading the wxcpcltoutlook-test.php script but then it goes away and doesn't return with subsequent restoration of the script to original? That's probably a result of server caching, which IMHO doesn't always clear with a browser refresh. Sometimes several refreshes are needed to see the effects of otherwise stable supporting script changes. That phenomenon can quickly flatten one's forehead.
That is correct, Jerry. However, in addition to a 0MB cache as mentioned (and doing multiple clears), I also tried different browsers which had not seen this page so there was no chance to cache it with those.
Forehead a little flatter now...? ](*,)
Hit 118° a little while ago making a new official record for the day. Maybe it's the heat... :roll:
Server caching will NOT clear immediately with browser refreshes or a different browser.
-
I found the problem with ajaxgizmo. It seems if there is a window.onload() javascript function, ajaxgizmo doesn't update. I found the same problem with a few other of my scripts that I'll have to fix as well. Meanwhile, the revised files are in wxcpcoutlook2.zip in this thread's first post.
Tell me if your mouseover problem persists, John.
-
Ran the scripts exactly as received. Gizmo working fine on both, as is (was) the mouseover.
Added my analytics call to one. Gizmo continued to work, but mouseover was gone (however a click did work).
Bottom line - put the analytics call back in place and changed the mouseover to false. Gizmo and click works fine on both.
Sorry...
-
Ran the scripts exactly as received. Gizmo working fine on both, as is (was) the mouseover.
Added my analytics call to one. Gizmo continued to work, but mouseover was gone (however a click did work).
Bottom line - put the analytics call back in place and changed the mouseover to false. Gizmo and click works fine on both.
Sorry...
No problem, John. I've included as a band-aid fix for Google Analytics users hardcoded 'mouseover' and 'onclick' versions of the scripts in 'wxcpcoutlook3.zip' in the first post of this thread.
-
Your reputation as a bug-finder is intact, John :-)
Good. Would hate to break stride here... ;)
First and foremost - MO version works as intended! Thank you, Jerry!
Couple minor items..
Still missing a few 'px' designations, which upsets FF with a big X in the CSS area. Forgot to write down the line numbers. Search for echo $horImgWidth?>; and echo $horImgHeight?>; in both MO scripts (didn't check the OC scripts).
The supplied links <a href="wxcpcltoutlook.php"> and <a href="wxcpcoutlook.php"> to change pages will fail if using the modified scripts without first renaming them (or changing the links in the code). A simple note in the readme might help.
Sorry - that's all I found... :roll:
-
First and foremost - MO version works as intended! Thank you, Jerry!
You're welcome, John.Couple minor items..
Still missing a few 'px' designations, which upsets FF with a big X in the CSS area. Forgot to write down the line numbers. Search for echo $horImgWidth?>; and echo $horImgHeight?>; in both MO scripts (didn't check the OC scripts).
The supplied links <a href="wxcpcltoutlook.php"> and <a href="wxcpcoutlook.php"> to change pages will fail if using the modified scripts without first renaming them (or changing the links in the code). A simple note in the readme might help.
Sorry - that's all I found... :roll:
I appreciate your quick location of the seemingly inevitable bugs, John. #-o I should have caught the links, but they're fixed now in wxcpcltoutlook3a.zip found in the first post of this thread. Version 3a corrects the internal links for the ...-ga-... files that pointed back to the original files pair rather than the new ones. It also hopefully kills the last of the missing 'px' entries. I don't think FF will complain--for a change I checked. It does warn twice about 'parsing width' values, but doesn't point to the line(s). I'm pretty sure it's the -1's that cause the width to be set at viewport width for centering purposes. One of these days I'll learn how to do it properly without 'Jerry-rigging' it. :-)
-
One of these days I'll learn how to do it properly without 'Jerry-rigging' it. :-)
Oh, no - then who will I have to pick on... ;)
Thanks again.
-
I discovered a problem with the scripts' display of the long-term outlook mouseover or onclick menus. The ' c;' entries there prevented breaking these at logical places, and therefore the menus weren't wrapping properly. :oops: All of the ' c;' entries have been replaced with ' ' (spaces) in the wxcpcoutlook3b.zip scripts. They now wrap correctly.
-
More :oops:.
I also discovered another problem today, Sunday the 14th. Version 4 revises the logic that determines when to switch the maps to NWS creation during the current month rather than
the previous month. This version replaces all prior versions due to the flawed date-switching logic in those scripts that switched months prematurely during the third week on Sun-Wed. Please discard the previous versions and use this one.
-
Ver 4 working good here.
Thanks
Cheers
:grin:
MikeyM
-
Good to know, but I have more bad news. #-o :oops: I discovered serious flaws in the logic that displays the long-term map images near the transition of the calendar to a new year. These flaws have hopefully been corrected in Version 5, available as wxcpcltoutlook5.zip in the first post of this thread.
I would urge anyone who is using a prior version to update to this latest version.
Let me know if you discover any more errors in the scripts.
-
HI Jerry
Just installed Ver 5 and on the "Near Term Forecast" for the 1 month and 3 month maps there is a "gray" box showing up under the maps. Not sure if that is supposed to be there or not?
Thanks
MikeyM
-
The gray box is my answer to variable height images. When you mouse over/click on a shorter graphic, the space is filled in by a gray background box. Is that what you're referring to?
Looking at your site, I think not. It looks like the gray box is a part of your template.
-
Hi Jerry
The gray box shows up when I mouse over the "Near Term" 1 month or 3 months. I didn't make any changes to the templates, just uploaded them to my server as I received them from the .zip file. Hope that's what you were asking. I'll take a look at the templates tomorrow as it's getting a little late here and I have to be up and out early in the morning.
Tomorrow I'll reload the Ver 4 scripts and see what happens, also the Ver 3 scripts.
EDIT: I just looked at : http://www.cnyweather.com/wxcpcoutlook.php , not sure what version he's running, but no gray boxed on "Near Term" 1 or 3 months.
EDIT 2: OK I realized it because I'm not using a "gray" background. I'll fix that tomorrow. Thanks
Have a good evening.
:-)
MikeyM
-
I think I see what's happening. When you change themes, the browser's cached 'white_box.png' is displaying rather than the newly written appropriately colored one. Clearing the browser's cache (<shift><F5> in Chrome for instance) will display the newly created and appropriately colored background 'white_box.png'. I'll look around for a solution to the problem, but I can't promise anything other than what's below, which may be preferable to some anyway.
If you prefer a white 'white_box.png' background with all themes, just edit the script<?php function make_white_box () {
// Create a 4:3 image
global $horImgWidth, $horImgHeight;
$im = imagecreatetruecolor($horImgWidth,$horImgHeight);
$CSSstyle = '';
# was there a style selected from the form input
if (isset($_COOKIE['CSSstyle'])) {
$_SESSION['CSSstyle'] = $_COOKIE['CSSstyle'];
$CSSstyle = $_COOKIE['CSSstyle'];
} else if (isset($_SESSION['CSSstyle']) and $_SESSION['CSSstyle'] <> '' ) {
$CSSstyle = $_SESSION['CSSstyle'];
}
if (preg_match('|black|i',$CSSstyle) ) {
$white = imagecolorallocate($im, 192, 192, 192);
}else if (preg_match('|silver|i',$CSSstyle) ) {
$white = imagecolorallocate($im, 202, 202, 202);
} else {
$white = imagecolorallocate($im, 255, 255, 255);
}
// Use identical RGB values for shades of gray to black at 0, 0, 0--e.g. 192, 192, 192 for light gray.
// Draw a white or gray rectangle depending upon color style in use.
imagefilledrectangle($im, 0, 0, $horImgWidth, $horImgHeight, $white);
// Save the image
imagepng($im, './white_box.png');
imagedestroy($im);
}
?>
to read <?php function make_white_box () {
// Create a 4:3 image
global $horImgWidth, $horImgHeight;
$im = imagecreatetruecolor($horImgWidth,$horImgHeight);
$white = imagecolorallocate($im, 255, 255, 255);
// Draw a white rectangle.
imagefilledrectangle($im, 0, 0, $horImgWidth, $horImgHeight, $white);
// Save the image
imagepng($im, './white_box.png');
imagedestroy($im);
}
?>
-
In response to MikeyM's observation regarding the 'white_box.png' behavior during theme switching Version 5a adds an option, $allWhiteBox, to the near-term scripts to use all white 'white_box.png' backgrounds rather than switching to shades of gray for the black and silver themes. Switching to shades of gray may be overkill and is beset by browser cache issues if viewers switch themes back and forth. Just set $allWhiteBox = true to use all white box backgrounds. The white box was originally created to maintain the same aspect ratio of the US when switching maps. Without it the vertical compression/expansion of the US during switching is very distracting.
The modified files are in wxcpcltoutlook5a.zip which is available in the first post of this thread.
-
Thanks Jerry.
That works. Sorry to make extra work for you. I forgot that I'm using a modified "black" css file to add shading on my webpage in the "Black" mode.
Thanks again.
Cheers
:-)
MikeyM
-
I awoke early this morning to the realization that the map-date-switching algorithm was broken. Version 5b further revises the logic that determines when to switch maps by relying on a day-of-month of the third-Thursday-of-the-month calculation rather than day-of-week calculations. While the prior algorithm worked this month, it would fall over some months. The new algorithm should solve this problem. Version 5b is available in the first post of this thread.
-
I inadvertently deleted a needed variable, $day_mon, from Version 5b, and Version 5c remedies that problem. It has been verified to change map months at 7:30am US/Eastern time on the 3rd Thursday of the month (this month, anyway). I've verified the 3rd Thursday's accuracy through Jan, 2014 which is as far as the algorithm will go since it relies on the current year's calendar to calculate the 3rd Thursday of each month.
-
The latest script, Version 5c, successfully switched to the current maps today, Aug 15 which is the third Thursday of this month, at the correct time, so I think it's stable for now.
-
Working fine here with 5C. Thanks Jerry
Cheers
:grin:
MikeyM
-
Just wondering if you would be willing to share your wxdrought3.php page? Like the way it operates and seems to fit in with this current series, some of the information is duplicate but like the interface.
-
Just wondering if you would be willing to share your wxdrought3.php page? Like the way it operates and seems to fit in with this current series, some of the information is duplicate but like the interface.
This script is included in the package I posted here (http://www.wxforum.net/index.php?topic=17639.msg170932#msg170932).
Regards,
-
Thanks... Funny, I actually searched for this script here and it came up empty. Appreciate the redirect!
I have it uploaded now but the mouseovers are not working at all. On your page you mouseover, say, temperature and the image changes without the need to click. Mine does not change unless I click the link. Any help here?
http://www.k3jae.com/wxDrought3.php (http://www.k3jae.com/wxDrought3.php) for your review.
-
The script displayed erroneous dates in some of the links this month. There were also problems in Nov and Dec that I uncovered while debugging the script. All of the charts displayed correctly, but the links didn't match the chart dates at times. Version 6 in the first post hopefully fixes those problems. I've also updated the fixed mouseover and fixed onclick scripts for Google Analytics compatibility. Version 5c is no longer available.
-
Jerry
For some reason the 1 month and 3 months are not updating in the "Near Term" version. 6 - 10 days and 8-14 days are correct, but 1 month and 3 month are showing an update of 16 Oct.
"Long Term" version is correct with data from yesterday 20 Nov. http://mikeymsweather.com/wxcpcoutlook.php
Any ideas? :?
Cheers
MikeyM
-
Jerry
For some reason the 1 month and 3 months are not updating in the "Near Term" version. 6 - 10 days and 8-14 days are correct, but 1 month and 3 month are showing an update of 16 Oct.
"Long Term" version is correct with data from yesterday 20 Nov. http://mikeymsweather.com/wxcpcoutlook.php
Any ideas? :?
Cheers
MikeyM
Hit alt-F5 to refresh the page & flush the browser's cache...I see the correct charts here.
-
Thanks Jerry
It was strange as it was OK in IE, Chrome and Pale Moon and the problem only showed up in FireFox. It was fine after a "reload".
Thanks again.
Cheers
:grin:
MikeyM
-
Jerry,
I've had your scripts on my "to-do" list for a long time. Today, as a cold wind howled outside and listening to some Emma Veary Hawaiian music on Pandora, I decided now was the time! Did the installation and all appears to be working just fine. Great script. I put mine under my "Forecast and Advisories" menu item.
Thanks for you efforts... =D>
-
The NWS CPC has moved the Long-Term Outlook from experimental to production. The old Version 6 no longer displays updated maps and has been removed. Version 7 in the first post displays the 'Official' production CPC long-term outlook charts.
-
Thanks for the update Jerry
Cheers
:grin:
MikeyM
-
Jerry, is the V7 you now have posted really the latest? All still say 'version 6' at the top of the code, and the page title within the code still says 'experimental'.
Thanks.
-
Once again John Gillett has unearthed the errors of my ways :-) Thanks for doing so, John! I had completely forgotten what the alternate versions were all about in my haste to publish the click-mouseover configurable version that I use. They indeed needed modification before they could function properly again.
I've now updated all of the Long Term Outlook scripts in Version 7a in the first post above.
-
OK, Jerry - lessee here. That makes 194 burps found over the years, usual pricing is $75/burp - but my special friend pricing applies here ($62.99) - plus tax for the idiots in DC... My, my - that's a bunch!
Let's just leave it at 'my pleasure', and thank you for the kind note. :roll: :grin:
-
There was an error in the logic for computation of the first Thursday of the month that resulted in the display of stale 'One Month Outlook' maps from the last day of the prior month rather than the maps which were freshened on the third Thursday of each month. This has been corrected in the latest version that's available as 'wxcpcoutlook.zip' on my scripts page (https://www.gwwilkins.org/gwwScripts.php).
It was a subtle bug that escaped my notice for all this time! :oops:
-
And there was yet another error in my 'first Thursday' logic in that it was using the first Thursday for last month, not the current month. :oops:
Corrected zip available as above.
-
Hi Jerry and Happy New Year
I just updated and when I go to the Long Term Maps the data appears to be 1 map off, ie if I hover over FMA (Feb,Mar Apr) the map show MAM (May,Jun,Jul). Not sure if I'm doing something wrong or the CPC hasn't updated the maps.
Thanks for all your updates.
Cheers
MikeyM
-
Thanks, MikeyM! I'll look into it sometime soon, but probably not today. I suspect it has to do with the map update times that the NWS has changed and now my script needs to 'catch up'. Nope, bad guess!
Well, that was fairly easy! The same problem with 'first Thursday' originated in this very old script. Also, the links were all 'http://" rather than "https://" so no padlock was displayed in the browser address bar.
Additionally, this script never made it into my scripts page (https://www.gwwilkins.org/gwwScripts.php). The script doesn't validate at present, and I haven't the time to sort it out right now.