✅ Why in gods name does DateTime.Parse change the hours in this oneliner?
DateTime dateTime = DateTime.ParseExact("2023-06-01T10:00:00.0000000Z", "yyyy-MM-ddTHH:mm:ss.fffffffK", CultureInfo.InvariantCulture);
datetime.Hour will be 12 after parsing the string where it clearly should be 10
19 Replies
canton7
REPL Result: Success
Console Output
Compile: 383.839ms | Execution: 74.291ms | React with ❌ to remove this embed.
Cannot reproduce
What timezone are you in?
Germany, +2 atm due to winter time
but i dont see how that should matter if i pass zulu time
Sehra
REPL Result: Success
Result: DateTimeKind
Compile: 229.750ms | Execution: 26.354ms | React with ❌ to remove this embed.
add
, DateTimeStyles.RoundtripKind
Filing a bug report for the Microsoft.Graph package now, they were omitting this and changing our times
I wondered whether it was converting to your local timezone for display
Actually, it is getting parsed as
Local
, despite the Z
Yeah the roundtrip kind docs explain it
DateTimeKind is only preserved when using that enum value
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
please please please get into the habit of using DateTimeOffset instead of DateTime in your code everywhere you possibly can. DateTimeOffset contains the UTC offset with the data so is lossless. DateTime is very very weird in how it stores data. DateTime only knows UTC and "local" time. But your local time zone can change! Laptops easily move across state lines, even while an app is currently running. (So you are in California running an app, put some DateTime instance in memory, hop on a plane to New York, then resume your app 3 time zones ahead. What on earth will be contained within the DateTime instance?) But wait, this was a lie. DateTime actually has 3 ways it keeps track of time: UTC, local (which can change while an app is running), and unspecified (unknown, essentially). (Unknown = I don't know if it's UTC or local, the app will figure it out later and call ToUniversal or ToLocal before calling ToString or any comparison routine.) But wait, this was a lie. DateTime actually has a secret fourth way of storing data that's not exposed in the standard API surface! It's truly an abomination of a type. All of this nonsense is irrelevant if we just pretend DateTime doesn't exist and we instead use DateTimeOffset everywhere.- GrabYourPitchforks (start: https://discord.com/channels/143867839282020352/143867839282020352/988353756108312607)
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
i think the problem was in https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/main/src/Microsoft.Graph/Extensions/DateTimeTimeZoneExtensions.cs
GitHub
msgraph-sdk-dotnet/src/Microsoft.Graph/Extensions/DateTimeTimeZoneE...
Microsoft Graph Client Library for .NET! Contribute to microsoftgraph/msgraph-sdk-dotnet development by creating an account on GitHub.
IK i already had filed a bug
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
I dont think that will be in scope, that bugfix should be easy though
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
We just came across it too, sucks major league. Especially since its such an easy fix for MS.Graph https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/main/src/Microsoft.Graph/Extensions/DateTimeTimeZoneExtensions.cs#L67
literal oneliner
You came across that bug as well? 😄
no, looked it up based on description
^^