It is currently September 24th, 2020, 2:17 am

⭐ Weather.com

Post your work-in-progress and completed skins to share and discuss.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com

Post by jsmorley »

SilverAzide wrote: June 17th, 2020, 5:46 pm Yes! I found that note a while ago too!

That's why I was thinking that subtracting 3 hours from the "observation time" would always return the proper day/month names. However, the part they don't seem to explain is what the definition of "Local Apparent Time" is. I don't think it is the same as "local time", in that I could swear I saw the day/night switchover happening at 4pm sometimes. I have a suspicion that "Local Apparent Time" does NOT include any Daylight Saving Time adjustment, so when DST is in effect, the switchover happens at 4PM in that location. RIght now it's at 3AM/3PM for sure, but come DST time, I'm not sure. Just have to wait and see, I suppose...
I have found that using any variant of "observation time" isn't going to be good for detecting the month and day for the forecast days.

I'm not forcing a days worth of seconds (86400) times the number of days anymore. That approach was based on the "observation time", and at some points in the day that could get out of sync with the long name of the day being returned as a string. I'm now using a field "validTimeLocal" that is returned for each day, and I'm pretty sure, or at least hoping, that this solves the issue.

Observation Time is about "Current" values, and has no literal bearing on any "Forecast" stuff, even "Today".
User avatar
SilverAzide
Posts: 955
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com

Post by SilverAzide »

Yincognito wrote: June 17th, 2020, 5:49 pm ... but for weather.com the "today" starts at 7 AM (even if the sun already rose before, in summer days) and the "tonight" probably around 7 PM (even if the sun didn't yet set in summer days). Another possibility is that those 3 AM / 4 AM (day name thingy) and those 3 PM / 4 PM (day forecast thingy) "anomalies" are related, maybe something regarding centralizing / updating stuff on their servers for the next periods. Just my 2 cents. :???:
You might have to trust me on this, but I can assure you (unfortunately!!) that "today" definitely starts long before 7AM. I wake up at 4:30AM, and it is already "today" by that time. The switchover happens at something around 3AM/4AM, not sure exactly which.... it depends on that "Local Apparent Time" definition.
Gadgets Wiki GitHub More Gadgets...
User avatar
SilverAzide
Posts: 955
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com

Post by SilverAzide »

jsmorley wrote: June 17th, 2020, 5:53 pm I'm now using a field "validTimeLocal" that is returned for each day, and I'm pretty sure, or at least hoping, that this solves the issue.
I'm hoping this works too. It's gonna require staying up really late to confirm... ;)
Gadgets Wiki GitHub More Gadgets...
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com

Post by jsmorley »

SilverAzide wrote: June 17th, 2020, 6:00 pm I'm hoping this works too. It's gonna require staying up really late to confirm... ;)
Or getting up just little early in your case...
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com

Post by jsmorley »

I really don't care when they change from "today" to "tonight" or "tonight" to "today". I imagine it is like 4pm and 4am or something. It's all just a "forecast" and its up to them what frame of time they decide to forecast for. As long as all the days and months and such match up and are in sync, I'm fine with it. I make it a point not to get up at 1:30am to see if the forecast has changed from "tonight" to "today"...
User avatar
SilverAzide
Posts: 955
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com

Post by SilverAzide »

jsmorley wrote: June 17th, 2020, 6:04 pm I really don't care when they change from "today" to "tonight" or "tonight" to "today". I imagine it is like 4pm and 4am or something. It's all just a "forecast" and its up to them what frame of time they decide to forecast for. As long as all the days and months and such match up and are in sync, I'm fine with it. I make it a point not to get up at 1:30am to see if the forecast has changed from "tonight" to "today"...
LOL! Yes, agreed, as long as the days line up, it's all good!

To veer this thread slightly back toward the main topic... Should there be any concern with skins using this template about performance issues from having so many measures? The number of child measures is pretty ginormous now... something like 950, was it? It SEEMS okay, I've got 3 weather skins running all the time and Rainmeter is still using ~1.0% of my CPU, but I wasn't sure if there's any real benefit to cutting down the number of active measures (like organizing blocks of measures into groups, so if you only wanted a 5 day forecast instead of 15 days, you could turn off a group).
Gadgets Wiki GitHub More Gadgets...
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com

Post by jsmorley »

SilverAzide wrote: June 17th, 2020, 6:15 pm LOL! Yes, agreed, as long as the days line up, it's all good!

To veer this thread slightly back toward the main topic... Should there be any concern with skins using this template about performance issues from having so many measures? The number of child measures is pretty ginormous now... something like 950, was it? It SEEMS okay, I've got 3 weather skins running all the time and Rainmeter is still using ~1.0% of my CPU, but I wasn't sure if there's any real benefit to cutting down the number of active measures (like organizing blocks of measures into groups, so if you only wanted a 5 day forecast instead of 15 days, you could turn off a group).
I don't see any noticeable difference between 3 days and 15 days on CPU usage. It's a boatload of measures, but 90% of them are "child" WebParser measures, which use virtually no CPU. The relatively few "parent" measures do all the work.

I did break it up already if you look at the current .rmskin. I have distinct includes for 3, 5, 7, 10, and 15 days. I didn't really do this for performance reasons, but just to make it easier to work with the skin in About/Skins.

I don't doubt that there is some small difference in the amount of resources used, nothing is entirely free. It's not going to be much, but I see no reason not to use the 5-day include if your skin is designed for 5 days.
User avatar
SilverAzide
Posts: 955
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com

Post by SilverAzide »

Excellent, thank you!
Gadgets Wiki GitHub More Gadgets...
User avatar
Yincognito
Posts: 2593
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com

Post by Yincognito »

SilverAzide wrote: June 17th, 2020, 6:15 pmTo veer this thread slightly back toward the main topic... Should there be any concern with skins using this template about performance issues from having so many measures? The number of child measures is pretty ginormous now... something like 950, was it? It SEEMS okay, I've got 3 weather skins running all the time and Rainmeter is still using ~1.0% of my CPU, but I wasn't sure if there's any real benefit to cutting down the number of active measures (like organizing blocks of measures into groups, so if you only wanted a 5 day forecast instead of 15 days, you could turn off a group).
It's not a performance hit from the CPU usage point of view, like jsmorley pointed out, but it surely is a performance hit from the quantity of data being parsed / downloaded, that's for sure. Bottom line, getting stuff parsed is going to take longer than back in the wxdata days where a short xml was parsed in a matter of nanoseconds or something, LOL. My biggest concern regarding this is weather.com trying to stop or irreparably change the page source data to avoid heavy trafficking from it, including Rainmeter skins updating a couple of minutes away and downloading MB of data from all around the world. I saw a post on StackOverflow by an Indian guy who tried to get 100000 aggregate records using a (supposedly, legit) API key, and even if the data obtained in that way is way smaller than downloading the entire main page like we do, I reckon he's not the only one trying such overload on weather.com. I think I saw / read somewhere that one of the reasons they deprecated / retired wxdata was the traffic overload on it (compared to their "expectations" or "common sense recommendations") - hopefully this won't be the case with the main site, but I obviously can't guarantee it.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com

Post by jsmorley »

It's one of the reasons I use a UserAgent string in my @Include file. That has two objectives for me. One, to ensure that what I get in the skin with Debug=2 and what I get in my browser are the same thing. There is some comfort in that. Two, I'd just as soon have the site see a connection from my browser every 10 minutes, rather than "Rainmeter WebParser Plugin".

I'm not overly concerned about weather.com getting slammed by WebParser. What the skin is doing is downloading exactly what any browser hitting the site would do, and trust me, that is a HUGELY popular site, and a few thousand Rainmeter users hitting it every 10 minutes is going to be line noise to it. I have no idea what their traffic on the site looks like, but I can well imagine that hundreds of thousands of people are on it any any given second.