Thanks for your suggestion of changing my Mac's Time Zone to reproduce the bug! I filed FB15767197 with a simple program attached to that bug. Program demonstrating the problem. The bad Dates occur with both MusicKit and iTunesLibrary, so hopefully the underlying bug can be fixed for them both.

[quote='812604022, DTS Engineer, /thread/767837?answerId=812604022#812604022'] That depends on exactly what it’s doing wrong. Do you have code for that library? [/quote] No, it's iTunesLibrary in macOS. All of my code is on my GitHub. Adding to the debugging clues, last night it returned dateModified values back in line with what they were before the DST change! I'm guessing that somewhere deep in that code it was not fully aware DST has changed. Strangely, the dateAdded changes remain. I know this will sound crazy, but I think iTunes has had this bug since at least 2007, when I started dumping its data regularly!

This appears to be fixed in newer OSs.

Thanks @DTS Engineer (Quinn)! I used your suggestion and it worked. I made a wrapping App Bundle that lets it work again and again when loaded by my LaunchAgent.

moved to original post

moved to original post

Fixed w/ proper annotations in iOS18.

With the same code, the warning is gone in Xcode 15.4, where I target x.5 releases of iOS and macOS.

I think I have just about solved the problem. My shell script launched both my own binary and git. I have updated my binary to launch git via Process. Now my launchd plist launches my binary itself instead of using the shell. It has asked for UI permission to run each time (3 times now). I'm not sure why my answer hasn't been sticky yet...

Aha. My shell script is sandboxed. Not sure if I can add permissions to a shell script. I am going to try to create a Swift command line tool that uses Process to invoke git. Updates to come.

I'm sorry; I see the message. I do not understand why the ViewModifier (which knows the View) is different in this manner than the View itself. Thanks.

I assume they must install your app via TestFlight.

See https://github.com/apple/swift-package-manager/issues/6993 At least I found a workaround. xcstrings no longer need the "en.lproj" directory, and it appears maybe SPM is looking for that. If I add a "fake" file in that directory it will build!

Thanks! This is terrific.

It works great now that the CDN has caught up. Thanks again!