⭐ Weather.com - Parsing the V3 JSON

[OnyxBlack]

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.

I initially tried to work around that by simply grabbing the full day name, feeding that value (e.g. "Monday") to the timestamp option with appropriate TimeStampFormat %A, and then converting the output via the Format option using %a and FormatLocale. All I ever got was errors with "invalid timestamp bla bla". I assume because the TimeStamp has to refer to an absolute, specific point in time.
A similar yet more complicated route might be to generate a timestamp for every day we know are in the forecast fields, and using that as the source for both the long and the abbreviated day names. Maybe taking into account the time at which the data switches between today being yesterday and starts being today, as SilverAzide mentioned.
Anyway, sorry for any bugs that have crept into the file on my account.

[balala]

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

Disagree. They are not at all.

[pul53dr1v3r]

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

In German: Montag, Dienstag, Mittwoch, Donnerstag...
in Serbian: Ponedeljak, Utorak, Sreda, Četvrtak...
in Russian: Понедельник, Вторник, Среда, Четверг...

[OnyxBlack]

In Geman: Montag, Dienstag, Mittwoch, Donnerstag...
in Serbian: Ponedeljak, Utorak, Sreda, Četvrtak...
in Russian: Понедельник, Вторник, Среда, Четверг...

German is Mo, Di, Mi, Do, etc.

[SilverAzide]

I initially tried to work around that by simply grabbing the full day name, feeding that value (e.g. "Monday") to the timestamp option with appropriate TimeStampFormat %A, and then converting the output via the Format option using %a and FormatLocale. All I ever got was errors with "invalid timestamp bla bla". I assume because the TimeStamp has to refer to an absolute, specific point in time.
A similar yet more complicated route might be to generate a timestamp for every day we know are in the forecast fields, and using that as the source for both the long and the abbreviated day names. Maybe taking into account the time at which the data switches between today being yesterday and starts being today, as SilverAzide mentioned.
Anyway, sorry for any bugs that have crept into the file on my account.

The more I look at it, the more convinced I am that simply subtracting 3 hours (or 4?) from the CurrentObservationTimeStamp will work close enough. But it does need to be done for every reference in the [@Forecast...] measures, including the month name and day of month measures. By "close enough" I mean there's still going to be a window of time where it's off because the observation timestamp will be delayed by ~10 minutes, but that's better than 3-4 hours.

For example:

Code: Select all

[@ForecastTodayDayShort]
Measure=Time
TimeStamp=([@CurrentObservationTime:TimeStamp] - 10800)
DynamicVariables=1
FormatLocale=#Language#
Format=%a

[@ForecastDay2DayShort]
Measure=Time
TimeStamp=([@CurrentObservationTime:TimeStamp] + (86400 * 1) - 10800)
DynamicVariables=1
FormatLocale=#Language#
Format=%a

etc...

EDIT:
Looks like it's 3 hours. If you point your weather skin to a location where it is just before 3AM local time, you'll see the transition from "tonight" to "today" in the data at the first (or second) reading past 03:00.

[jsmorley]

The more I look at it, the more convinced I am that simply subtracting 3 hours (or 4?) from the CurrentObservationTimeStamp will work close enough. But it does need to be done for every reference in the [@Forecast...] measures, including the month name and day of month measures. By "close enough" I mean there's still going to be a window of time where it's off because the observation timestamp will be delayed by ~10 minutes, but that's better than 3-4 hours.

For example:

Code: Select all

[@ForecastTodayDayShort]
Measure=Time
TimeStamp=([@CurrentObservationTime:TimeStamp] - 10800)
DynamicVariables=1
FormatLocale=#Language#
Format=%a

[@ForecastDay2DayShort]
Measure=Time
TimeStamp=([@CurrentObservationTime:TimeStamp] + (86400 * 1) - 10800)
DynamicVariables=1
FormatLocale=#Language#
Format=%a

etc...

I'm still not sure I follow the problem exactly, and I'm hesitant to brute force this to something inaccurate. Feels to me that subtracting 3 or 4 hours from every timestamp will make early morning hours become "yesterday" instead of "today". I need to chew on this some. I'm not convinced that this isn't just a quirk of weather.com that we might want to "live with". Much like the fact that the current day forecast data changes from "today" to "tonight" sometime in the early afternoon, certainly not "night" by my estimation.

[Yincognito]

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).

Yeah, I know about this since the beginning - it was the same for wxdata, as far as I recall. Me, I learned to live with it, not paying much attention to this.

[jsmorley]

Yeah, I know about this since the beginning - it was the same for wxdata, as far as I recall. Me, I learned to live with it, not paying much attention to this.

Yeah, maybe I don't fully understand, but I have never noticed a problem. Of course I NEVER use either the long or the short name for the current day, as when it is Saturday, that is "Today / Tonight" for me, and never "Saturday / Sat" as that just feels weird to me. I'm less anal about "Tomorrow", as I'm fine with either "Tomorrow" or "Sunday" for that.

[SilverAzide]

I'm still not sure I follow the problem exactly, and I'm hesitant to brute force this to something inaccurate. Feels to me that subtracting 3 or 4 hours from every timestamp will make early morning hours become "yesterday" instead of "today". I need to chew on this some. I'm not convinced that this isn't just a quirk of weather.com that we might want to "live with". Much like the fact that the current day forecast data changes from "today" to "tonight" sometime in the early afternoon, certainly not "night" by my estimation.

Yeah... fortunately, this only effects the short day name, month name, and day of the month measures; all the important data is unaffected.

[jsmorley]

Yeah... fortunately, this only effects the short day name, month name, and day of the month measures; all the important data is unaffected.

Just as an aside, it just changed from "today" to "tonight" for me, about 3:15pm or 3:30pm or so my time. I'm pretty ok with that, as I would postulate that a "forecast" for "today" becomes less relevant about that time, and the forecast for "tonight" becomes more interesting. I guess any decisions you are going to make based on today's weather have already been made by then.