Yincognito wrote: ↑February 13th, 2020, 2:27 pm
That field is the only one not included in my skin. I have no need for max/min temperatures for the 24h day, since I've always used the day/night cycles (and their temperatures). It's true that visually, on the main page, there are these "Max" and "Min" temperatures for the 24h day (hence, taken as such by skin authors), but those are actually the day and night cycle's temps internally. From a purely technical point of view, there are no min or max temps (bar the "max temperature since 7am" you noticed, and that is for past tense) in TWC (and wxdata) sources, they just happen to label them as such on the main page since almost always the day cycle is warmer than the night one, everywhere on Earth.
Up to you of course. I find that [@CurrentMaxTemperatureSince7AM] works perfectly to maintain the display of today's "high" temperature even after the day has changed from "today" to "tonight". As you say, everywhere in the world, the maximum temperature during the day is going to be higher than at night. Personally, I kinda like having the "forecasted" OR "historical" value for "high" displayed for today, no matter what the hour. It's why they have that in the JSON, and I like to take advantage of it. Of course I don't use it until it actually is what weather.com treats as "night".
And really, it wouldn't matter a bit if for some reason there was a higher temperature at "night' than was ever achieved during the day. I doubt that would happen, but I guess it could, and [@CurrentMaxTemperatureSince7AM] would still reflect the overall day's "high" in that case. It's not constrained by "day" or "night".
What weather.com returns for the forecasted "day" temperature is in fact the "high" for the day, and the forecasted "night" temperature is in fact the "low" for the day. It's just what they mean, and what they can only mean. I just like that there is also a perfectly accurate way to deal with the fact that there can't be any "forecast" for "day" once it is "night". weather.com is one of the few sites or apps that throw away the display of "today's high" once that becomes "historical" instead of "forecasted" at some point in the day. Take a look at how Yahoo Weather shows it.
I disagree. It's not a challenge, it's normal - that's how the moon behaves, it's not the sun, after all. The day part of the TWC timestamp is, from my observation, accurate - I just compared the 13 Feb and 20 Feb data for Reykjavik (Iceland) between TWC and timeanddate.com and, bar the rounding of minutes, they are the same (both the time and the date). What you said about the rise/set data could be said regarding the old wxdata, where they were horrendously messy, but I'm actually "over the moon" (so to speak) about the fact that the TWC data seems accurate in that respect. If you can briefly paste here an instance when the TWC data seems inaccurate in that regard, I would be interested to see it.
Not saying that anything is inaccurate as such, just that the "date" part of the timestamps feels confusing to me. During a given day's cycle, the moon first "sets", generally at some point in the morning, but it might be in the early afternoon. Then the moon "rises", generally at some point in the night of that day, or the early morning of the next day. The "date" part of the timestamps always reflect today's date, when I'm not sure that is entirely, technically true. The moon "rise" time might well actually be tomorrow morning. I may be looking at this all wrong, and to be honest I just barely even care. I don't alter my daily schedule much based on what phase of the moon it is.
As far as the missing timestamp information, it doesn't really matter if they return null or "" as either is going to blow up a Time measure. What I do when this happens is to return the timestamp for the "day" in general, (always there) so the Time measures are happy and aren't hammering the error log, then just ignore it and set the value to "N/A" with the Format option on the Time measure. I gather you don't use Time measures in your stuff, but just parse the timestamp. That's up to you, but I prefer giving the option to the user to format date and time strings any way they like. I like "Thursday, February 13, 2020 at 10:02 am EST" myself, and you just can't get that parsing the timestamp.
