⭐ Weather.com - Parsing the V3 JSON

[jsmorley]

I guess could see a skin that uses both "conditions" and "cloud cover" as distinct things.

"The weather is Sunny, and the skies are Clear".
"the weather is Fair, and the skies are Partly Cloudy".

[Yincognito]

I guess could see a skin that uses both "conditions" and "cloud cover" as distinct things.

"The weather is Sunny, and the skies are Clear".
"the weather is Fair, and the skies are Partly Cloudy".

That would be nice, I think. Assuming one has the space for it.

[SilverAzide]

Ok, I have fixed the "Current Conditions" and posted a new .rmskin in the first post of this thread.

This keeps the original (but fixed) @CurrentConditions, and adds three new measures:

@CurrentCloudCoverPhrase
@CurrentConditionsMedium
@CurrentConditionsShort

Thank you!
There is only one other minor glitch that I've noticed and I'm not sure it is fixable. The @ForecastDayNDayShort and @ForecastDayNDayLong measures show different day names between approximately midnight and approximately 3 or 4 in the morning when TWC decides to switch from "it's tonight" mode to "it's today" mode. It's because the long name is coming from their data and the short name is a Time measure based off the observation time. Their "tomorrow" doesn't move to "today" at midnight, it moves at 3-4 AM ("apparent local time", whatever the heck that means).

[jsmorley]

Thank you!
There is only one other minor glitch that I've noticed and I'm not sure it is fixable. The @ForecastDayNDayShort and @ForecastDayNDayLong measures show different day names between approximately midnight and approximately 3 or 4 in the morning when TWC decides to switch from "it's tonight" mode to "it's today" mode. It's because the long name is coming from their data and the short name is a Time measure based off the observation time. Their "tomorrow" doesn't move to "today" at midnight, it moves at 3-4 AM ("apparent local time", whatever the heck that means).

I'll look at that. May not be any way to fix that, as the "short name" isn't part of the data, and there is no easy way to abbreviate all day of the week names in all the supported languages. A time measure can do it, but then you have to depend on a timestamp, which while perfect accurate for the "observation time", may or may not match the "data" at any given moment.

[jsmorley]

You could always use the "long" day of week name, and use a Substitute to shorten them. But that has the "language" issue to deal with.

[SilverAzide]

You could always use the "long" day of week name, and use a Substitute to shorten them. But that has the "language" issue to deal with.

Just thinking... what about subtracting 3 hours from the timestamp? That way it will still be the "proper" day, one that matches their data. It won't be a perfect match, but it would be closer.

[jsmorley]

Just thinking... what about subtracting 3 hours from the timestamp? That way it will still be the "proper" day, one that matches their data.

Wouldn't that just push the problem to the other end?

[SilverAzide]

Wouldn't that just push the problem to the other end?

Hm... I don't... *think* so...? This is making my brain itch. I think shifting the "short day name" timestamps by 3 hours would sync closer to their data, but the "other end" is either in the past or future, beyond the sliding window of their data. It's all based on quantum mechanics, I think.

[jsmorley]

Hm... I don't... *think* so...? This is making my brain itch. I think shifting the "short day name" timestamps by 3 hours would sync closer to their data, but the "other end" is either in the past or future, beyond the sliding window of their data. It's all based on quantum mechanics, I think.

That damn dead cat again...

[Yincognito]

You could always use the "long" day of week name, and use a Substitute to shorten them. But that has the "language" issue to deal with.

Not necessarily. The abbreviation of the first 3 chars is almost the same in most languages...