Seattle and SF are in the same time zone, so why would they have different timezoneOffset values?
Also, what does -29359 even mean? It translates to -8.1527… hours, which isn’t a meaningful time zone offset.
Since you are curious, this is an app I started developing in 2011, and it was beleaguered with every imaginable edge case with regard to time zones and daylight saving time. My app is all about converting solar time to whatever time zone you want to look at sometime from, in whatever calendar, in any time past or present, which often involves crossing every possible arbitrary human-made boundary in time and space.
Being able to create a standardized time zone based on the location (converted to seconds from GMT), allowed me to do certain data conversions to get the day without having to worry about whether or not daylight saving was in effect at one calendar date but not another that the date picker might choose.
And it worked fine for many years until the latest iOS. Presumably Apple had a reason for introducing the ability to create time zones based on seconds from GMT, and I found it useful. So, I hope that answers your question.
This bug continues to plague my app and I get complaints almost daily from users since iOS 18 came out.
What's really strange though is that the bug appears to be in the way the Date Picker handles the calendar set to this time zone in the appearance of the picker. The month set as February appears as January but returns as February, so it is as if the visual month is one off.
It would be a lot less weird if it was the day that was one off, but it's the month!
