11 ms·
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
by 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 agoFile 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 agoI 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.