calendar

Same here. I thought is was my CalDigit TS3+. I also have a OWC Thunderbolt Hub. My issue was it was on my 2019 MacBook Pro 16 (maxed out) running Ventura. I happened to have a 14 Apple MacBook M1 Max with 64GB, so I manually migrated my apps thinking it might be a software issue. I didn't migrate the usual culprits; AVG, CleanMyMac. Sure enough My system had issues with a LaCie External HDD, connected to the OWC, that I used for TimeMachine. It wouldn't stay mounted. Then on overnights - some maybe an additional clue - I'd come in in the morning, and the M1 rebooted. Kernel panic. Details below. I also swapped out the CalDigit TS3+ for a TS4. I never thought it could be the OWC, so I'll disconnect that to see if the issue goes away. I'm going to try some attempts to isolate. OWC currently connected via CalDigit. I'm going to connect that directly. Step at a time. Crash report: `panic(cpu 2 caller 0xfffffe001b97fb18): dart-usb2 (0xfffffe200640c000): DART(DARTBLK) error: SID 1 TTBR invalid exception after shut

It appears that styles use the Hebrew numbering system while templates do not: let fullyHebrewLocale = Locale(identifier: he-IL@numbers=hebr) let fullyHebrewCalendar = { var calendar = Calendar(identifier: .hebrew) calendar.timeZone = TimeZone(identifier: Asia/Jerusalem)! calendar.locale = fullyHebrewLocale return calendar }() let latinHebrewLocale = Locale(identifier: he-IL@numbers=latn) let latinHebrewCalendar = { var calendar = Calendar(identifier: .hebrew) calendar.timeZone = TimeZone(identifier: Asia/Jerusalem)! calendar.locale = latinHebrewLocale return calendar }() struct ContentView: View { let date = Date.now var body: some View { List{ Text(u{2067}FSH:tu{2069} + date.formatted(formatStyleH.attributed)) .environment(.layoutDirection, .rightToLeft) Text(u{2067}DFHS:tu{2069} + dateFormattedHS(date: date)) .environment(.layoutDirection, .rightToLeft) Text(u{2067}DFHT:tu{2069} + dateFormattedHT(date: date)) .environment(.layoutDirection, .rightToLeft)

Hey Jason, Was having a look into the Technote you shared and, regarding the Protect user privacy with information property list keys section, the documentation mentions the following: Important On iOS 17 or later, if your app doesn’t include usage description keys, or only includes the older NSCalendarsUsageDescription key for describing events access, iOS automatically denies any access request. But, immediately after, it mentions this: To access a person’s calendar events or reminders through EventKit or EventKit UI, your app needs to include descriptions for the following if your app links to iOS 10 or later, and runs on iOS 10 through iOS 16: NSCalendarsUsageDescription, which is a fallback if your app runs on iOS 17 or later and doesn’t include descriptions for NSCalendarsWriteOnlyAccessUsageDescription or NSCalendarsFullAccessUsageDescription. I find this very confusing as the two concepts seem to be the opposite of each other. Am I misunderstanding something or is there an issue with the docu

Unfortunately the entire write-only access feature is the right answer to the wrong question. No person and no app ever wants to add an event to a calendar. We may talk about adding an event colloquially, but what we mean is: Add the event if it is not already there. If the event is already there, modify it if necessary. For a human example: when you confirm a meeting and say I will put it in the diary, that does not mean that you open your diary, see the meeting is already in the diary, and then add it a second time. But that is what the assumptions behind the new API imply. In my case the app is maintaining a one-a-day list of future events for the next 365 days (it does this in a separate calendar with a separate name, not in Home or Work). Each time the app is run it needs to add whatever future dates have not yet been added. The new API does not allow this because there is no way of knowing what has already been added. In addition (in parallel to your case): the exact content of the eve

I found this explanation very useful in the context of debugging an off-by-one-day bug in my crossword app. It's a classic scenario where crosswords are referenced by date but without a specific time, except that the date is usually reckoned by the time zone of the host publication. I thought I would share an example of how I'm addressing the issue using the defaultDate technique, but generalizing it to choose a middle of the day time that should work with whatever time zone (Quinn's example uses a fixed relative time interval that is specific to Sao Paolo). Given a date formatter that already has the desired time zone set on it: var midDayComponents = DateComponents(hour: 12) midDayComponents.calendar = Calendar(identifier: .gregorian) midDayComponents.timeZone = dateFormatter.timeZone dateFormatter.defaultDate = midDayComponents.date It seems that all you need is an hour, a calendar, and a time zone to come up with a suitably mid-day date. I hope this helps somebody!