4 ms·

What's wrong with DateTime? Seriously curious

Mindless2112 4y ago
It should have been two types (UtcDateTime and LocalDateTime), and Unspecified should never have been a thing.
Smaug123 4y ago
I have spent weeks of work time trying to track down DateTimes, work out their intended semantics, replace them with a user-defined type, and fix the resulting fallout when it turned out that people were relying on bugs. Unclear who thought it would be a good idea to have the same type mean all of "I don't know whether I have time zone relevance", "I am in UTC", and "I am in local time" depending on some runtime enum it contains.
- Const-me 4y ago
  File systems need backward compatibility. 40 years ago, it wasn’t clear people gonna invent Internet and start moving files across time zones. Keeping file modification time according to local clock was reasonable idea at that time. The FAT file system (1977) stores local time, and no time zones. CDFS a.k.a. ISO 9660 (designed in 1986) was better than FAT but still less than ideal, it keeps local time, and offset in 15 minutes intervals between local time and GMT. That’s not generally convertible to UTC either. Windows NT came with the proper file system which keeps time in UTC (also high-resolution, 100 nanoseconds versus 2 second in FAT) but most people only upgraded to NT and NTFS in 2002 with WinXP, and various external drives were still using older file systems without UTC timestamps. .NET only dropped the support of Windows 9.x in .NET 3.0 (2006), and even afterwards they probably wanted to support all these external drives. Including timestamps of the files on these drives.
  - Smaug123 4y ago
    I guess I'm just more willing to accept solutions of the form "recognise the mistake we made, and create a whole new API that is more correct" than they were.
moomin 4y ago
1) The API is incredibly error prone. To the extent that even today EF6 Core can do random things to your dates if you’re not careful. 2) It’s the wrong model for representing dates and times so you end up with stuff like the midnight convention (which would be fine if it wasn’t for point 1) In short: in 99 instances out of 100, you would be better off using DateTimeOffset, DateOnly or TimeOnly.

It should have been two types (UtcDateTime and LocalDateTime), and Unspecified should never have been a thing.

I have spent weeks of work time trying to track down DateTimes, work out their intended semantics, replace them with a user-defined type, and fix the resulting fallout when it turned out that people were relying on bugs. Unclear who thought it would be a good idea to have the same type mean all of "I don't know whether I have time zone relevance", "I am in UTC", and "I am in local time" depending on some runtime enum it contains.

Const-me 4y ago
File systems need backward compatibility. 40 years ago, it wasn’t clear people gonna invent Internet and start moving files across time zones. Keeping file modification time according to local clock was reasonable idea at that time. The FAT file system (1977) stores local time, and no time zones. CDFS a.k.a. ISO 9660 (designed in 1986) was better than FAT but still less than ideal, it keeps local time, and offset in 15 minutes intervals between local time and GMT. That’s not generally convertible to UTC either. Windows NT came with the proper file system which keeps time in UTC (also high-resolution, 100 nanoseconds versus 2 second in FAT) but most people only upgraded to NT and NTFS in 2002 with WinXP, and various external drives were still using older file systems without UTC timestamps. .NET only dropped the support of Windows 9.x in .NET 3.0 (2006), and even afterwards they probably wanted to support all these external drives. Including timestamps of the files on these drives.
- Smaug123 4y ago
  I guess I'm just more willing to accept solutions of the form "recognise the mistake we made, and create a whole new API that is more correct" than they were.

moomin 4y ago

1) The API is incredibly error prone. To the extent that even today EF6 Core can do random things to your dates if you’re not careful. 2) It’s the wrong model for representing dates and times so you end up with stuff like the midnight convention (which would be fine if it wasn’t for point 1) In short: in 99 instances out of 100, you would be better off using DateTimeOffset, DateOnly or TimeOnly.