Library uses DateTime instead of DateTimeOffset resulting in +1 hour data
See original GitHub issueHi,
I normally use DateTimeOffset
to ensure the real date never gets missed regardless of the local date. I see that DateTime
gets used here and my guess was it just takes care of it but it seems it does not hence my traces are shown with +1 hour in zipkin.
Is there a design reason why DateTime
gets used and not DateTimeOffset
? I can send a PR but was wondering it could have another significance.
Thanks Ali
Issue Analytics
- State:
- Created 6 years ago
- Comments:8
Top Results From Across the Web
DateTime vs DateTimeOffset
DateTimeOffset is a representation of instantaneous time (also known as absolute time). By that, I mean a moment in time that is universal ......
Read more >Converting between DateTime and DateTimeOffset
Although the DateTimeOffset structure provides a greater degree of time zone awareness than the DateTime structure, DateTime parameters are used ...
Read more >4 Common Datetime Mistakes in C# And How to Avoid Them
In cases like this, it'd make more sense to either (a) store the datetime in UTC along with the user's time zone or...
Read more >The case against DateTime.Now - Code of Matt
If we are asking for DateTimeOffset.Now , we will get a value that represents the local time on the computer where the code...
Read more >datetime — Basic date and time types
Source code: Lib/datetime.py The datetime module supplies classes for ... The result is rounded to the nearest multiple of timedelta.resolution using ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
yeah much more clear.
FWIW most libraries don’t actually pass things like DateTime around anyway (rather numbers corresponding to epoch micros or a Clock facade that might be backed by something like DateTime).
If DateTime cannot be coerced to UTC, then sounds like a bad choice, but I’ll leave it to y’all decide what to do.
Yeah, thanks I believe this should work. I am closing this issue.