fix: Support nanosecond precision as far as possible with DateTimeOffset #2578
Conversation
jskeet
added
the
do not merge
|
I've marked this as "do not merge" because we need to get confirmation that this is what we want to happen, rather than changing the service implementation. |
| _ => ThrowFormatException() | ||
| }; | ||
|
|
||
| // If we receive "2023- |
| public void GetDateTimeOffsetFromString_Invalid(string input) => | ||
| Assert.Throws<FormatException>(() => Utilities.GetDateTimeOffsetFromString(input)); | ||
|
|
||
| // Not on formatting for tick-of-second for the theory data in the following tests: |
There was a problem hiding this comment.
| // Not on formatting for tick-of-second for the theory data in the following tests: | |
| // Note on formatting for tick-of-second for the theory data in the following tests: |
This fixes googleapis#2575, for both parsing and formatting. It does mean that `x.CreateTimestamp = x.CreateTimestamp` potentially loses information (2023-10-27T10:32:45.123456789Z would become 2023-10-27T10:32:45.123456700Z) but that's the best we can do. This doesn't change the DateTime handling at all; it's still brokenly-culture-sensitive, and only formats to millisecond precision. The generated DateTime properties are now obsolete though, so it's probably best to leave them as they are.
jskeet
force-pushed
the
more-precision
branch
from
52c5eb2 to
a933c3e
Compare
|
Hi, |
|
@DayLightDancer: We're still confirming exactly what the position is. Given #2580, I'm actually looking at a bigger change (moving this implementation to some new methods). I wouldn't personally expect this to be fixed within the next week - there's a fair amount to coordinate, even when we've confirmed the situation. I would suggest just parsing the raw-suffixed property for now. |
|
We'll be using #2595 to address this instead. |
|
(Don't worry @DayLightDancer , it's still very much going ahead - just in a slightly different form.) |
This fixes #2575, for both parsing and formatting. It does mean that
x.CreateTimestamp = x.CreateTimestamppotentially loses information (2023-10-27T10:32:45.123456789Z would become 2023-10-27T10:32:45.123456700Z) but that's the best we can do.This doesn't change the DateTime handling at all; it's still brokenly-culture-sensitive, and only formats to millisecond precision. The generated DateTime properties are now obsolete though, so it's probably best to leave them as they are.