It is currently July 10th, 2020, 12:50 pm

⭐ Weather.com

Post your work-in-progress and completed skins to share and discuss.
User avatar
Yincognito
Posts: 1893
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com

Post by Yincognito »

SilverAzide wrote:
June 17th, 2020, 4:57 pm
Man... are you guys living on the same planet as me? The "maximums" don't always happen during the day, cold fronts and warm fronts move through all the time whenever they feel like. Plenty of nights are warmer than days... doesn't happen real often, but it happens. What DOES happen is TWC stops sending "forecast" data when there's nothing more to forecast, as the day is essentially over and any "day forecast" is not applicable. They call this "night" for some reason, which is a little annoying when the sun is still shining.

Note the high of the day was at 1AM:

Annotation 2020-06-17 124630.png
Check these two documents:
- API Standard V3:
API - Standard - v3 - Forecast - 5 Day Daily Forecast for Personal Weather Station Owners .pdf
- Weather XML Data Feed:
guide.pdf
On the 1st, read the note on the first page. On the 2nd (yeah, I know, it's outdated, but still), read the section 8.6 Forecasts.
I know these don't answer the question as to why it's like it is, but the notification regarding this is there. All we can do is to speculate with a more or less degree of accuracy on the matter, as only weather.com know exactly the reasoning behind this. In my view, that reasoning is surely based on something. :confused:
You do not have the required permissions to view the files attached to this post.
User avatar
SilverAzide
Posts: 884
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com

Post by SilverAzide »

Yincognito wrote:
June 17th, 2020, 5:17 pm
Check these two documents:
- API Standard V3:
API - Standard - v3 - Forecast - 5 Day Daily Forecast for Personal Weather Station Owners .pdf
- Weather XML Data Feed:
guide.pdf
On the 1st, read the note on the first page. On the 2nd (yeah, I know, it's outdated, but still), read the section 8.6 Forecasts.
I know these don't answer the question as to why it's like it is, but the notification regarding this is there. All we can do is to speculate with a more or less degree of accuracy on the matter, as only weather.com know exactly the reasoning behind this. In my view, that reasoning is surely based on something. :confused:
Yes! I found that note a while ago too!
PLEASE NOTE: The daypart object as well as the temperatureMax field OUTSIDE of the daypart object will appear as null in the API after 3:00pm Local Apparent Time.
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...
Gadgets DeviantArt More...
User avatar
Yincognito
Posts: 1893
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com

Post by Yincognito »

SilverAzide wrote:
June 17th, 2020, 4:57 pm
They call this "night" for some reason, which is a little annoying when the sun is still shining.
Well, it's not actually "night", it's "tonight", really - which has nothing to do with the sun still shining. I get what you say and I agree from a "commoner" / "civilian" (i.e. not involved in the profession of doing those forecasts) point of view, 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. :???:

P.S. It's not like you're left with no data for the 3 PM - 7 PM period, as one still has the hourly forecasts, and of course, the observation conditions.
User avatar
jsmorley
Developer
Posts: 21009
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: 884
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 DeviantArt More...
User avatar
SilverAzide
Posts: 884
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 DeviantArt More...
User avatar
jsmorley
Developer
Posts: 21009
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: 21009
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: 884
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 DeviantArt More...
User avatar
jsmorley
Developer
Posts: 21009
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.