A year ago I filed feedback FB13055082 about this and I just realized that it was marked as "works as currently designed". I need help understanding why this is the expected behavior. For the feedback example I used Nepal, which is +5:45 from GMT. When the UTC offset is not at an hour interval, the dates returned by DayWeather and HourWeather do not match. I’ll request weather with a start date of Aug 25 at 12:0:0 AM GMT+5:45 and end date of Sep 3 at 12:0:0 AM GMT+5:45. The first daily forecast returns a date of Aug 25, 2023 at 12:0:0 AM GMT+5:45, which is what I expect. It's midnight in Nepal and the start of the day. If in my code I call (correct calendar).startOfDay(for: ) I'll also get this same time back. However, the first hourly forecast returned is for Aug 25, 2023 at 12:45:0 AM GMT+5:45 which is NOT the start of the day in Nepal or the start I asked for. It is 45 minutes off. How is the hourly data not starting at the time I requested the expected behavior? Especially when the day data does start at the time I requested.

My application engages the following: Generates and properly displays a selected location with MapKit. Generates SwiftUI WeatherKit information for a selected MapKit location. Generates correct Timezone WeatherKit [DayWeather] Sunrise and Sunset times within my timezone using the [ForEach] function. Generates incorrect Timezone WeatherKit [DayWeather] using the ForEach function, while retrieving Sunrise and Sunset times outside of my timezone. I modified my MapKit application to locate and retrieve weather information at specified locations. The application correctly illustrates all the weather information views I want to display without issue for a MapKit selected location. One view exception presents itself specific to the [ForEach] function inside a WeatherKit view, which retrieves Sunrise and Sunset information. The retrieved Sunrise and Sunset times for a selected timezone location outside of my identified timezone are not correct. My application does not generate nor apply an incorrect timezone identifier, such as [Europe/Paris] anywhere within the application, but the following view code segment surely hiccups. The selected timezone location view presents the Sunrise and Sunset time information as an equivalent time within my timezone, displayed in the images below. The issue happens to be within the view's following ForEach function code: Text(day.sun.sunrise?.formatted(.dateTime.hour().minute()) ?? "?") For the moment, I am struggling to discover how to correct the above code to properly display the [Sunrise] and [Sunset] times within a [ForEach] function. I do not know whether this issue happens to be inherent to WeatherKit's ForEach function, but most likely I am not properly applying the code to reflect the selected location's timezone format within the [Text]. I have not found a solution to apply within the [ForEach] function to correct this issue, as the application iterates through the supplied WeatherKit DayWeather information. I know I can retrieve the correct current TimeZone time for a selected location with the following code: func main() { let d = Date() // Show the [VARIABLE f] as [HOUR / MINUTE] such as [12:23PM] var f = Date.FormatStyle.dateTime.hour().minute() print("The [LOCAL TIME ZONE TIME with MAIN] :: \(d.formatted(f))") f.timeZone = TimeZone(identifier: "Europe/Paris")! print("The [SELECTED TIME ZONE TIME with MAIN] :: \(d.formatted(f))\n") } // Call the function main() The above code does not solve my application's issue, because the code simply returns the selected location's current timezone time relative to my current timezone time. So, if my timezone time happens to be 1:40 PM, then the above code generates a timezone time for a selected location, such as Paris to be 9:40 PM. I know a [View] does not respond to the incremental function code, such as stated above. As a side note :: My application displays the WeatherKit information through a Container and Hosting Controller, where the application's SwiftUI ContentView calls :: if let dailyForecast { TestForecastView(dailyForecast: dailyForecast, timezone: timezone) } If you have a moment, I appreciate your possible corrective suggestions, which would be very welcome ... :] Best regards, jim_k My TestForecastView Code with the attached generated views follow: import Foundation import SwiftUI import CoreLocation import WeatherKit struct TestForecastView: View { let dailyForecast: Forecast<DayWeather> let timezone: TimeZone var body: some View { Spacer() .frame(height: 10) Text("Sunrise Sunset") .font(.system(size: 24, weight: .bold)) .foregroundStyle(.white) Text("Ten Day Forecast") .font(.system(size: 11, weight: .medium)) .foregroundStyle(.white) Spacer() .frame(height: 4) VStack { ForEach(dailyForecast, id: \.date) { day in LabeledContent { HStack(spacing: 20) { RoundedRectangle(cornerRadius: 10) .fill(Color.orange.opacity(0.5)) .frame(width: 120, height: 5) .padding(.leading, 2) .padding(.trailing, 0) VStack { Image(systemName: "sunrise") .font(.system(size: 24.0, weight: .bold)) .foregroundColor(.yellow) Text(day.sun.sunrise?.formatted(.dateTime.hour().minute()) ?? "?") .font(.system(size: 10.0)) } .frame(width: 50, height: 20) VStack { Image(systemName: "sunset") .font(.system(size: 24.0, weight: .bold)) .foregroundColor(.yellow) Text(day.sun.sunset?.formatted(.dateTime.hour().minute()) ?? "?") .font(.system(size: 10.0)) } .frame(width: 50, height: 20) Spacer() .frame(width: 2) } } label: { Text(day.date.localDate(for: timezone)) .frame(width: 80, alignment: .leading) .padding(.leading, 30) .padding(.trailing, 0) } .frame(width: 380, height: 52) .background(RoundedRectangle(cornerRadius: 4).fill(LinearGradient(gradient: Gradient(colors: [Color(.systemBlue), Color(.black)]), startPoint: .topLeading, endPoint: .bottomTrailing)).stroke(.black, lineWidth: 6).multilineTextAlignment(.center)) .shadow(color: Color.white.opacity(0.1), radius: 4, x: -2, y: -2) .shadow(color: Color.white.opacity(0.1), radius: 4, x: 2, y: 2) } } .padding(.top, 20) .padding(.bottom, 20) .padding(.leading, 20) .padding(.trailing, 20) .contentMargins(.all, 4, for: .scrollContent) .background(RoundedRectangle(cornerRadius: 10).fill(Color.black.opacity(0.0)).stroke(.gray, lineWidth: 4)) } // End of [var body: some View] } // End of [struct TestForecastView: View] My resultant code views :: Calgary Paris

We pass a CLLocation to the new WeatherService monthlyStatistics() BUT in the returned metadata the CLLocation data does NOT match what we sent in the request. For example, send lat -27.1480114 long -109.4273371 in the monthly stat request and get back data for lat -27.148000717163086, long -109.427001953125. There’s no mention in the documentation of the returned location being “close to” the requested location. If this is working as designed how close are the results allowed to be? In my small sample they seem to be around 45-55 meters away. I’m considering less than 100 meters away to be a match, but don’t know if that’s correct.

Starting in the last week or two the daily forecast returned by weatherkit rest api changed to 9 days instead of 10 days if I don't pass in the dailyStart and dailyEnd paramters. Now, if I pass in those parameters to get me anything more than 9 days then I get 400 error. 9 days or less works. Obviously something changed in the api. Apple, please fix this asap!!!

I am using WeatherKit to display relevant weather information to the User in my App. I also thought it would be helpful to show any time-sensitive WeatherAlert. I would like to direct the User directly into the system Weather app to get more details/information. weather://open ... works... Is this a faux-pas? Is there a approved/proper way of doing this? I know WeatherAlert.detailsURL exists but I figured it may be useful for the User to see all details related to weather right from the source.

I would like to request two enhancements to the Weather app: Add a Celsius/Fahrenheit conversion option directly on the home page, rather than requiring users to access it through the three-dot menu. Consider displaying both Celsius and Fahrenheit scales side by side, without requiring users to choose a conversion option(only if its feasible for your team). This would be particularly helpful for users who are familiar with both scales, such as Asians living in America. Thank you for considering my request!

Hello Apple team, I would like to request a feature to display the past temperature data (e.g., last 7 days) for each place in the Weather app(Especially past 24 hours of data for any given city ). Just like how it shows future 7-10 days of data. This would allow users to quickly view temperature trends and patterns for users like us to re-member how that day was like,etc,etc. Please consider adding a 'Past Weather' section or a graph that shows the temperature fluctuations over the past week. Thank you for considering my request!

Hi. The WWDC video of the v2 weatherkit api showed some examples for the REST API. However, they were very limited. The documentation for the REST API is currently for the v1 weatherkit API. When will the documentation for the v2 API be released? There are some new features of the v2 that I would really like to use, but I can't without knowing the new v2 REST API specifications. Any guidance would be much appreciated. Thanks!

Upon requesting forecast data for more than 9 days, the API would return "400 Bad Request". Here are some values I tried (as of 2024-07-02T15:00:00Z): (dailyStart is in past) dailyStart=2024-07-01T15:00:00Z dailyEnd=2024-07-11T15:00:00Z expected= 10 days forecast actual= 10 days forecast (dailyStart is current date, forcecast > 9 days) fails dailyStart=2024-07-02T15:00:00Z dailyEnd=2024-07-12T15:00:00Z expected= 10 days forecast actual= 400 Bad Request (dailyStart is current date, forecast <= 9 days) dailyStart=2024-07-02T15:00:00Z dailyEnd=2024-07-11T15:00:00Z expected= 9 days forecast actual= 9 days forecast (no values passed) fails dailyStart= dailyEnd= expected= 10 days forecast actual= 9 days forecast The official documentation says: dailyEnd: The time to end the daily forecast. If this parameter is absent, daily forecasts run for 10 days. dailyStart: The time to start the daily forecast. If this parameter is absent, daily forecasts start on the current day. This started happening sometime last week. Would someone please tell me what changed with the API? Thank you.

My app AirCompare is a smart home controller and makes system decisions based on local weather. Users have been seeing absurdly wrong (~10°F off) current temperatures, and of course that's a problem. I've seen similar complaints on Reddit and one poster claims that Apple switched from whatever DarkSky was using (which seemed accurate) to a predictive model from IBM. Compare iOS15 to iOS16 and you may see a large discrepancy in the Weather app. As a developer needing an accurate current temperature, I'm wondering if this is a temporary problem or whether we can expect this to continue going forward. If it's the latter, I'll need to find something more reliably accurate.

I'm just getting 400 error responses to my requests sent to the WeatherKit REST API... haven't changed anything in my code for months. Here is the verbose output from curl: # curl -v "https://weatherkit.apple.com/api/v1/weather/en/51.5203/-0.1775?dataSets=forecastHourly%2CforecastNextHour&hourlyEnd=2024-07-04T09%3A03%3A36.962Z&hourlyStart=2024-06-24T09%3A03%3A36.962Z" -H "Authorization: Bearer [REDACTED]" * Trying 23.73.4.202:443... * Connected to weatherkit.apple.com (23.73.4.202) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS header, Finished (20): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.2 (OUT), TLS header, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=weather-data.apple.com * start date: May 8 16:30:14 2024 GMT * expire date: Nov 4 16:40:14 2024 GMT * subjectAltName: host "weatherkit.apple.com" matched cert's "weatherkit.apple.com" * issuer: C=US; O=Apple Inc.; CN=Apple Public Server ECC CA 1 - G1 * SSL certificate verify ok. * TLSv1.2 (OUT), TLS header, Supplemental data (23): > GET /api/v1/weather/en/51.5203/-0.1775?dataSets=forecastHourly%2CforecastNextHour&hourlyEnd=2024-07-04T09%3A03%3A36.962Z&hourlyStart=2024-06-24T09%3A03%3A36.962Z HTTP/1.1 > Host: weatherkit.apple.com > User-Agent: curl/7.81.0 > Accept: */* > Authorization: Bearer [REDACTED] > * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * TLSv1.2 (IN), TLS header, Supplemental data (23): * Mark bundle as not supporting multiuse < HTTP/1.1 400 Bad Request < Server: Apple < Content-Length: 0 < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=31536000; includeSubdomains < X-XSS-Protection: 1; mode=block < Access-Control-Allow-Origin: * < X-Content-Type-Options: nosniff < Content-Security-Policy: default-src 'self'; < X-REQUEST-ID: ed7d038c-ef82-61d8-a2cb-4522ff7d32ca < X-Apple-Origin: fdcbff05-73b4-3a53-948b-343caa55a40e < Date: Mon, 24 Jun 2024 09:18:00 GMT < X-Cache: TCP_MISS from a23-73-3-202.deploy.akamaitechnologies.com (AkamaiGHost/11.5.2-56655770) (-) < Connection: keep-alive < * Connection #0 to host weatherkit.apple.com left intact

In the WWDC 2024 session, "Bring context to today's weather", it was mentioned that the Swift API now uses FlatBuffers when downloading the weather data to the client device. Will Apple's API for FlatBuffers be made available to developers? If its already in the SDK (client side) it would seem a shame to have to include another framework that does the same thing.

In the last 24 hours, I've noticed a huge increase in the number of connection failures to WeatherKit... more than half the calls are responding with responseFailed or -999 / -1001 errors. This is happening to customers in production, I have not managed to replicate the error on my own devices to get a complete error readout. Is anyone else experiencing this? System status shows green.

I've got an iOS app that uses WeatherKit SDK (not the REST API) to pull weather data. I'm getting reports from users today that it is failing to update today (June 5, 2024). When I run the app in a debugger I see: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Received authentication failure for request: 5E11C6A7-C255-4130-B1C7-93C3D6935210 On another attempt I got a 504 response. The Apple Weather app is also extremely slow to update (if at all) when adding a new location. And of course, https://developer.apple.com/system-status/ shows WeatherKit with a green light. Is anyone else seeing this? Edit: There seems to be a broad outage with weatherkit. The apple weather app is not working for several people reported here: https://discussions.apple.com/thread/255637780?sortBy=best Why is the developer dashboard showing a green light?! We need to be able to rely on these systems.

Looks like the Weather Kit API is down again. Anybody having the same issue?

Is there a way out of the WeatherKit REST API to get a textual summary of the weather like the iPhone app from Apple shows? Right now the local forecast on the iPhone app says "Sunny conditions from 7pm-8pm, with partly cloudy conditions expected at 8PM". Is this something the app rolls on it's own or is there a attribute-value pair in one of the returned JSON datasets that has this text. It's not in the "forecastDaily" dataset. *Humorous that it says "Sunny conditions from 7pm-8pm" because that's about the time the sun is setting. That forecast was from 1PM.

I was wondering if anyone knows why the sample project uses Task.detached everywhere because it seems highly non-standard, e.g. in ContentView: .task { Task.detached { @MainActor in await flightData.load() } } Instead, I would expect to see something like: .task { flightData = await controller.loadFlightData() } Or: .task { await controller.load(flightData: flightData) } Is the use of detached perhaps an attempt to work around some issue with ObservableObject published updates?

I have a Swift app that fetches current conditions and daily forecasts. It is in production and working without issues. My question is whether the fetch I am using counts as a single “request” for usage thresholds, or two (one for current conditions, one for daily forecast)? I need current conditions more often than daily forecast, so if this is counting as two requests, I could refactor the logic to get each separately as needed. But separating the requests would use more quota if the combined fetch counts as a single request. let service = WeatherService() let location = CLLocation(latitude: weatherData.lat, longitude: weatherData.lon) let startOfToday = Calendar.current.startOfDay(for: Date()) let endDate = Calendar.current.date(byAdding: DateComponents(day: 2), to: startOfToday)! let current: CurrentWeather let daily: Forecast<DayWeather> (current, daily) = try await service.weather(for: location, including: .current, .daily(startDate: startOfToday, endDate: endDate))

This is one of the comments to my weather app from users and also most of users think like that: Ever since Apple bought Dark Sky it's been wildly inaccurate. How does it possible? What you think?

Has anyone else been experiencing issues with the WeatherKit API recently? Since Saturday we've been seeing about 1.5% of our requests time out. Apple hasn't posted anything on their status page https://developer.apple.com/system-status/ and the issue doesn't seem to be getting any better.