TimeZoneInfo ID Mapping: Adapting .NET 6 Applications for Cross‑Platform Compatibility
0 reputation · 24 Feb 2024, 12:23 UTC
Goal
Ensure that a .NET 6 service correctly interprets and stores user‑specified time zones when it runs on both Windows and Linux containers. The service currently relies on TimeZoneInfo.FindSystemTimeZoneById and serializes DateTimeOffset values to JSON, but the same code throws on Linux when supplied with a Windows‑style ID such as 'Eastern Standard Time'.
Constraints
Windows uses registry‑based identifiers, while Linux/macOS use IANA IDs like 'America/New_York'. The TimeZoneInfo API throws a TimeZoneNotFoundException on unsupported IDs, and the mapping is not automatically translated. Additionally, the JSON serializer may drop the offset if the DateTime.Kind is Unspecified.
Questions
- What is the recommended pattern for storing a time zone reference that is portable across OSes?
- Should the application map Windows IDs to IANA IDs at startup, or rely on a third‑party library?
- How can we guarantee that serialization of
DateTimeOffsetpreserves the original offset when the application runs on Linux?