calendar

It work better (not perfectly) with month: 11 or 10 or 8. But not 9 !!! Very strange. That seems to be an old bug with .backwards: https://stackoverflow.com/questions/49202865/calendar-nextdate-is-acting-really-weird-when-using-backward-for-direction-o

I just tested with other time zones and the results are different... For some time zones, the result is correct, for others, not. I used the following code to print the result for all time zones. Optional(1970-08-31 23:00:00 +0000) for Europe/London Optional(1995-08-31 23:00:00 +0000) for Europe/Paris Optional(2002-08-31 22:00:00 +0000) for Europe/Vilnius Optional(2023-09-01 07:00:00 +0000) for America/Los_Angeles for zone in TimeZone.knownTimeZoneIdentifiers { var calendar: Calendar = Calendar(identifier: .gregorian) calendar.timeZone = TimeZone(identifier: zone) ?? .autoupdatingCurrent let matchingDateComponents: DateComponents = DateComponents(month: 9) let date: Date? = calendar.nextDate( after: Date.now, matching: matchingDateComponents, matchingPolicy: .nextTime, direction: .backward ) print(zone, date) }

Excellent, thanks for confirming. So I would say if you want to schedule a task for a specific time of day, like noon, Calendar can be great. And for simple time offset, like 4 hours from now, using Date().addingTimeInterval(..) seems better.

The properties you’re working with here are of type Date. A Date value is a floating point offset from the epoch (the start of 2001 GMT) and thus, in your terms, it’s always absolute [1]. How you create that Date value is up to you. If you want to generate it using Calendar, that’s fine. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I don’t consider it to be absolute because it’s based on the wall clock and thus can change if the device’s time changes, but coming up with words to discuss all these concepts is hard.

How is your app signed? A problem with the signature might prevent the OS from remembering that permission has been granted before. Thanks for the suggestion, but I don't think there's any problem with the signature. All other warnings (Calendar, Reminders, etc.) only get shown once, but this one gets shown each time. I think it only started appearing since macOS 14 Sonoma.

Thanks for the reply. Yes, you were on the mark. This was a warning that if you are running on macOS Sonoma you must use the new API requestFullAccessToEvents(completion:) or you won't have access to Calendar database.

Same issue. The same problem. Sometimes at work, but more often while sleeping. panic(cpu 1 caller 0xfffffe001a88ac50): skr.txausd.upipe:533:IDSClientChannelNexusOS: skr 0x0xfffffe24eead1c00 sg 0x0xfffffe24e43edea8 (idx 0) unable to satisfy mandatory allocation Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 23B81 Kernel version: Darwin Kernel Version 23.1.0: Mon Oct 9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 7BF1E8441DE38056EC1FDED67A9F101B Kernel UUID: 24DA617C-1A30-3D13-A4BB-7BF37E60644E Boot session UUID: E59838AD-1CA8-488B-8E0A-392D8116B1BC iBoot version: iBoot-10151.41.12 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x0000000011d58000 KernelCache base: 0xfffffe0018d5c000 Kernel slide: 0x0000000011d60000 Kernel text base: 0xfffffe0018d64000 Kernel text exec slide: 0x0000000013264000 Kernel text exec base: 0xfffffe001a268000 mach_absolute_time: 0x16ca94ed494 Epoch Time: sec usec Boot : 0x655864aa 0x000ee

∙View can conform to Equatable... True, .equatable() is no longer required, not sure what version that changed in. . ∙When view contains @ObservedObject... False, regardless of the outcome of ==, body is always called when any @Published property of the object changes or objectWillChange is published. . ∙Does view, that is Equatable, need to care about equality of its subviews.. No, a subview will just follow the same algorithm. Best to only init a View with the data it actually needs and uses in its body to keep invalidation tight. . ∙When view returns true on equality check... True, if you returned true from == but had @Environment(.calendar) var calendar and the calendar changed the body would still be called. This is the same behaviour as @ObservedObject in the 2nd question. . ∙When the observed object conforms to Equatable... In my testing the if an ObservedObject conformed to Equatable the == func was never called. My test code: import SwiftUI import Combine struct ViewTest {