На некоторых платформах, в зависимости от используемой версии Noda Time, идентификатор системного часового пояса недоступен, поэтому мы должны догадаться.Мы делаем это на основе переходов часовых поясов с 1 января текущего года на 1 января за 5 лет.(Это единственное место, где системные часы используются в производственном коде.)
Мы просим TimeZoneInfo
представить идею смещения UTC для множества различных моментов в этом интервале (каждый момент, когда любой часовых поясов IANA имеет переход).Затем мы «оцениваем» каждый часовой пояс IANA по значениям TimeZoneInfo
, чтобы увидеть, какая доля моментов возвращает одинаковое смещение UTC.Мы возвращаем идентификатор часового пояса с наибольшим количеством совпадений, при условии, что он составляет не менее 70% из них.
В вашем случае и Америка / Тихуана, и Америка / Лос-Анджелес имеют одинаковые переходы для5 лет 2018-2022.В формате tzvalidate :
2018-03-11 10:00:00Z -07:00:00 daylight PDT
2018-11-04 09:00:00Z -08:00:00 standard PST
2019-03-10 10:00:00Z -07:00:00 daylight PDT
2019-11-03 09:00:00Z -08:00:00 standard PST
2020-03-08 10:00:00Z -07:00:00 daylight PDT
2020-11-01 09:00:00Z -08:00:00 standard PST
2021-03-14 10:00:00Z -07:00:00 daylight PDT
2021-11-07 09:00:00Z -08:00:00 standard PST
2022-03-13 10:00:00Z -07:00:00 daylight PDT
2022-11-06 09:00:00Z -08:00:00 standard PST
Noda Time не может различить два часовых пояса в этом 5-летнем периоде, поэтому он возвращает тот, который был найден первым.(Не определено, какой из них он найдет первым - это то, что мы могли бы исправить, упорядочив часовые пояса по ID. Я опишу проблему для этого.)
Надеюсь, это поможет объяснить то, что вы видите- это не решает проблему, но показывает, что весь код (ваш и Noda Time) ведет себя разумно, в контексте ограниченной доступной информации.
Как предлагается в комментариях, вы можете захотетьдля решения этой проблемы используйте специальный код платформы: свойство .Name
Foundation.NSTimeZone.LocalTimeZone
на iOS и, возможно, свойство .ID
Java.Util.TimeZone.Default
на Android.