I'm confused about this one too... what is the point of the language parameter in the URL if it doesn't do anything? language string (Required) The language tag to use for localizing responses.

@rgilmour did you make any progress on this? I'm looking for a set of weather icons that correspond one-to-one with conditionCode (to avoid having to use a custom mapping to some other icon set). But at the very least it would be helpful if a similar mapping already exists out there for some other icon set.

I'm seeing this when fetching dataSets: "forecastHourly,forecastNextHour" in the REST API. I've been passing hourlyEnd in the form "2023-03-05T09:35:08.843Z" and it's worked fine until now. But I'm now getting "Request failed with status code 404". If I remove hourlyEnd completely, the request returns fine, but I then only get 24 hours of data. Any ideas?

And it doesn't make any difference (same 404 error) if I reduce the hourlyEnd to well within the 10 day limit, and make coincide with the start of the day... i.e. hourlyEnd: "2023-02-27T00:00:00Z" doesn't work either.

At the moment I'm using a ridiculous workaround, which is to request the forecastDaily dataSet even though I don't need it (along with forecastHourly which is what I really need). This is because I can then leave out hourlyEnd completely and still get the full 10 days of data, in view of the docs: hourlyEnd (date-time): The time to end the hourly forecast. If this parameter is absent, hourly forecasts run 24 hours or the length of the daily forecast, whichever is longer. dailyEnd (date-time): The time to end the daily forecast. If this parameter is absent, daily forecasts run for 10 days.

@VoyagerSpace... hmm, that's not ideal! The docs do say that countryCode "is necessary for weather alerts" but it doesn't say anything about timezone. Even if the docs were clear, these shouldn't ideally be required anyway from a usability point of view (it requires a couple of extra lookups if timezone and countryCode are not available, e.g. if all you have is a coordinate). In any case, I still can't get any alerts to show up at all, even when specifying timezone and countryCode. I've tried locations with active alerts on https://www.weather.gov/ and https://www.meteoalarm.org/. Any other tricks I'm missing? Perhaps the alerts are more limited that what is available elsewhere, and I just haven't found one yet that shows up? Here's an example of what I'm using now: URL: https://weatherkit.apple.com/api/v1/weather/en/35.244/-111.269 Query parameters: { dataSets: 'forecastHourly,forecastNextHour,forecastDaily,weatherAlerts', timezone: 'MST', countryCode: 'US' }

I've just noticed these (cloudCoverLowAltPct, cloudCoverMidAltPct, cloudCoverHighAltPct) appearing in return data for the forecastHourly dataset too. It didn't break anything (because I start on the assumption that return data for any data field may be null or missing completely), but I came here with similar questions/concerns. (a) they're not in the docs:: (b) are these always provided, for all locations? (c) are these now a permanent fixture in the REST API? (d) naming seems very misleading as mentioned by @Scott... Pct suggests percent but they're definitely all in the range 0-1 Thanks.

@FrameworksEngineer thanks for the reply. Yes I get the error when passing only hourlyEnd and not hourlyStart, which is apparently OK according to the docs: hourlyStart (date-time): The time to start the hourly forecast. If this parameter is absent, hourly forecasts start on the current hour. hourlyEnd (date-time): The time to end the hourly forecast. If this parameter is absent, hourly forecasts run 24 hours or the length of the daily forecast, whichever is longer. I'd just seen this post, which also suggests also passing hourlyStart (even though it's apparently optional), and indeed it does work. Probably a better workaround than asking for forecastDaily (and then just ignoring the return data). Will this behaviour be fixed (i.e. not being able to pass only hourlyEnd), or at least will the docs be updated? It would also be useful to have more information about the date-time format... at the moment I'm using ISO format, i.e. in javascript (new Date()).toISOString(), but I can't see from the docs for sure that this is correct (or whether it might break in future if I'm not using exactly the right format).

Where is best to file this sort of feedback? I note that @FrameworksEngineer does seem to roam around and interact on this forum.

It's more than once a day because I just had another one now, after the one received a few hours ago.

Thanks for the observations @stoic_matsumoto. I'll go down that route and see if I find the same. If true, and we need to second guess how many hours of data might be available in any given time zone to avoid a 400 error (and possibly taking into account other factors beyond our control) then this is indeed truly horrible :-0 Ideally we should just be able to ask for a certain number of hours from a given start time (defaulting to "now") and we should receive whatever is available up to the requested number of hours.

@stoic_matsumoto at present I calculate hourlyEnd to be 10 days after hourlyStart... Firstly, it's really not very elegant to have to do calculate either of these two dates in an absolute sense, and it should instead be possible to specify these relatively i.e. "10 days of data starting from now". Anyhow, I reduced the calculation from 10 days to 9 days (just to be sure), and indeed there now appear to be no 400 error responses. Hopefully a dev at Apple is reading these forums and can understand that this situation isn't ideal in any respect. I think these error responses must have only started around 5 or so days ago... so something must have changed in the backend around then. Would be nice to have the full 10 days of data back.

@AppleCare Staff @nialloriordan @Scott sure enough, these fields cloudCover[Low|Mid|High]AltPct have now vanished again without a trace. Which is a great shame :-(