3 ms·
I won't just say it doesn't satisfy my philosophy. I'll say additionally that the .NET standard library's `DateTime` type, which I believe is essentially the sa
by Smaug123 2y ago
I won't just say it doesn't satisfy my philosophy. I'll say additionally that the .NET standard library's `DateTime` type, which I believe is essentially the same and uses basically the same primitives, is so hard to use correctly that I have multiple times had to rewrite other people's programs, in one case completely from the ground up, to fix their correctness due to bugs I personally encountered in them in real life. I do have empirical evidence for some of my opinions, you know!
Time handling is one of the many cases where there is actually complexity in the domain, and if you refuse to model the complexity, that doesn't make the complexity go away; it just means you've got bugs.
- GoblinSlayer 2y agoI only saw DateTime.Now where StopWatch should be used and serialization inconsistency due to discrepancy in time zone database.
- Smaug123 2y agoSo it's famously difficult to write a correct date-time handling program, but my empirical observation is that it's considerably easier with a library like Noda Time which actually attempts to model some of the domain beyond "ticks since the epoch".
- GoblinSlayer 2y agoHow noda prevents you from using utc instead of StopWatch?