Oof, serves me right for not doing my own research. That was the time change info I was relayed by one of the support staff that I trust to get their details correct. :facepalm: But as far as I can tell from that wiki page, you are correct, being stuck on CST is the correct behavior.

This appears to be an issue on macOS 12.2.1 (21D62) too. Just received some crash logs from a customer that seems like it is the same crash signature (this is one of four different crashes that occured over the course of a week or so. Every crash has the same this basic signature): Date/Time: 2024-03-25 11:37:15.6659 -0400 OS Version: macOS 12.2.1 (21D62) Report Version: 12 Anonymous UUID: 11FA4AA4-0231-994D-2404-EA518B20693B Time Awake Since Boot: 860000 seconds System Integrity Protection: enabled Crashed Thread: 91 Dispatch queue: com.apple.CFNetwork.LoaderQ Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000058 Exception Codes: 0x0000000000000001, 0x0000000000000058 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [87810] ... Thread 91 Crashed:: Dispatch queue: com.apple.CFNetwork.LoaderQ 0 libdispatch.dylib 0x19ed97ce0 _dispatch_source_set_runloop_timer_4CF + 32 1 CFNetwork 0x1a3d997dc 0x1a3bb1000 + 2000860 2 CFNetwork 0x1a3d997dc 0x1a3bb1000 + 2000860 3 CFNetwork 0x1a3d99e9c 0x1a3bb1000 + 2002588 4 CFNetwork 0x1a3bcba88 0x1a3bb1000 + 109192 5 CFNetwork 0x1a3c4df40 0x1a3bb1000 + 642880 6 libdispatch.dylib 0x19ed80e60 _dispatch_call_block_and_release + 32 7 libdispatch.dylib 0x19ed82bac _dispatch_client_callout + 20 8 libdispatch.dylib 0x19ed8a330 _dispatch_lane_serial_drain + 672 9 libdispatch.dylib 0x19ed8aed8 _dispatch_lane_invoke + 444 10 libdispatch.dylib 0x19ed8c1c0 _dispatch_workloop_invoke + 1796 11 libdispatch.dylib 0x19ed95708 _dispatch_workloop_worker_thread + 656 12 libsystem_pthread.dylib 0x19ef3d304 _pthread_wqthread + 288 13 libsystem_pthread.dylib 0x19ef3c018 start_wqthread + 8 Thread 91 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x000012ec4f6a5421 x2: 0xffffffffffffffff x3: 0x000000003b9aca00 x4: 0x0000000000000000 x5: 0x0000000000000017 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x000000003b9aca00 x9: 0x800012ec4f6a5421 x10: 0x0000000055d4a800 x11: 0x0000000039387000 x12: 0x00000000016e3600 x13: 0x000000000003fca8 x14: 0x00000000ee269000 x15: 0x00000001f85f5540 x16: 0x000000019ed97cc0 x17: 0x00000001f9a44938 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000060000064ee60 x21: 0x000060000003d210 x22: 0x0000000000000000 x23: 0x0000000000000000 x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000114 x27: 0x000060000187c140 x28: 0x000060000187c140 fp: 0x000000016d8ee660 lr: 0x15290001a3d997dc sp: 0x000000016d8ee620 pc: 0x000000019ed97ce0 cpsr: 0x20001000 far: 0x0000000000000058 esr: 0x92000006 (Data Abort) byte read Translation fault It seems to somewhat be related to multiple threads initiating HTTP requests at once, as the crash seems to correlate to a log from our process which prints out some info about a HTTP request getting squashed (ie Mar 25 11:37:15 --- last message repeated 1 time ---) Unfortunately I haven't found a reliable way to reproduce this yet. However, after looking into this a bit further (and not knowing which version of libdispatch is included in macOS 12.2.1 (21D62)), from looking at the source for a version of libdispatch, it does seem to point to a null ptr deref is causing the crash (assuming x0: 0x0000000000000000 is getting passed in as first argument): void _dispatch_source_set_runloop_timer_4CF(dispatch_source_t ds, dispatch_time_t start, uint64_t interval, uint64_t leeway) { // Don't serialize through the source queue for CF timers <rdar://13833190> _dispatch_source_set_timer(ds, start, interval, leeway, false); } DISPATCH_ALWAYS_INLINE static inline void _dispatch_source_set_timer(dispatch_source_t ds, dispatch_time_t start, uint64_t interval, uint64_t leeway, bool source_sync) { if (slowpath(!ds->ds_is_timer) || slowpath(ds_timer(ds->ds_refs).flags & DISPATCH_TIMER_INTERVAL)) { DISPATCH_CLIENT_CRASH(ds, "Attempt to set timer on a non-timer source"); } ... } Id guess the offset of ds_is_timer in the dispatch_source_t struct happens to be 0x58, which is causing the KERN_INVALID_ADDRESS at 0x0000000000000058.