When reading a NodaTime ZonedDateTime from a PostgreSQL timestamp with time zone, we look at the PostgreSQL connection's Timezone parameter and return a ZonedDateTime in that timezone - this mimics the general PostgreSQL behavior when not using Npgsql.
We did not implement this for non-NodaTime DateTimeOffset, because PostgreSQL timezones are in IANA format, but .NET did not support those up to now - but that's been done: dotnet/runtime#49412. This means we can now start returning DateTimeOffset in the appropriate timezone, instead of in UTC the machine's configured timezone.
On the downside, this would be a breaking change; even more tricky, the IANA support is only going to be available in .NET 6.0, so this would possibly mean a behavioral change depending on which .NET is being used (or we throw NotSupported or something. We can discuss.
When reading a NodaTime ZonedDateTime from a PostgreSQL
timestamp with time zone, we look at the PostgreSQL connection's Timezone parameter and return a ZonedDateTime in that timezone - this mimics the general PostgreSQL behavior when not using Npgsql.We did not implement this for non-NodaTime DateTimeOffset, because PostgreSQL timezones are in IANA format, but .NET did not support those up to now - but that's been done: dotnet/runtime#49412. This means we can now start returning DateTimeOffset in the appropriate timezone, instead of in
UTCthe machine's configured timezone.On the downside, this would be a breaking change; even more tricky, the IANA support is only going to be available in .NET 6.0, so this would possibly mean a behavioral change depending on which .NET is being used (or we throw NotSupported or something. We can discuss.