ToDateTimeOffset method in ZonedDateTime truncates seconds in offset

[Дима Пугачев]

Hi!

I just want to apologize for my English..

In the process of using your library, we encountered the problem of converting from local time in Moscow to UTC and vice versa. Not even with the conversion to UTC itself, but from a local DateTime to a local DateTimeOffset.

The problem affects the time before 07/01/1919, since then in Russia the transfer was carried out with a difference of 03:30:48 (or 04:30:48). In your library, this translation is 03:31:19 (and 04:31:19, respectively). But in this case it is not so important. The main thing is that the offset was with seconds.

The bottom line is that offset seconds are truncated when the ToDateTimeOffset method is called on ZonedDateTime. I looked at the sources and saw that they were being rounded to minutes. I also understand why this is connected: DateTimeOffset "out of the box" does not allow creating an instance with an offset containing seconds ("ArgumentException: offset is not specified in whole minutes").

But we obviously did not expect the problem so deep :). Maybe somehow else I can get the conversion from local DateTime to local DateTimeOffset with the correct offset given the time zones (.net does not store daylight savings time offsets correctly by default)? I need this, since we first convert to DateTimeOffset, do some operations, and only then enter it into the database in UTC. And it is not at all obvious that 19 seconds are cut off in one direction, and they are taken into account in the other. And with each change, our time magically (or no longer) changes by 19 seconds.

Thank you!

[Jon Skeet]

As an aside, this sort of issue is best filed as a GitHub issue at https://github.com/nodatime/nodatime/issues with sample code.

As you say, DateTimeOffset cannot represent offsets with offsets which aren't a round number of minutes. There's nothing NodaTime can do about that - it's part of the BCL.

Instead, I'd suggest sticking to Noda Time types (e.g. OffsetDateTime as the Noda Time equivalent of DateTimeOffset) where this problem won't occur. Any time you use DateTimeOffset, you need to accept that you won't be able to accurately represent offsets like that.

Jon

--

---
You received this message because you are subscribed to the Google Groups "Noda Time" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noda-time+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/noda-time/72e756f5-0806-417c-a560-28b8738dece3n%40googlegroups.com.