The Treachery of Dates
updated 10 months ago; latest suggestion 10 months ago
Date(). Ceci n'est pas une date.
Few names in Cocoa are as misleading as Date. "May 13, 2018." That's a date. It has a month, a day, and year. It implies a particular calendar to make sense of it. It relies on a physical location to know when it starts and ends. But Date is "a specific point in time, independent of any calendar or time zone." How is that a date?
This is much more than an idle complaint about naming. Developers regularly misuse Date because they believe it's something it's not. I repeatedly encounter the same questions on Stack Overflow from people confused about what time zone a Date is in (it isn't in any time zone and can't be). In every new code base, I search for "86400" to find and fix the hidden DST bugs. Reading the API documentation isn't enough. Developers need to understand how calendars and dates work and how to think about them.
This talk will cover topics such as:
- Absolute time vs calendrical time and why you should be using DateComponents often
- Calendars and why you probably don't mean "current"
- Why 86,400 is useless and date math is hard, but doesn't have to be
- Finding calendar unit boundaries and why midnight isn't always where you left it
- Converting dates to strings and what those strings mean
- Time zones, and the demon that haunts our math: daylight savings time
- Storing dates and why "seconds since the epoch" is often the wrong tool
- Why TimeInterval is good, Java's Instant is better, millis is dangerous, and Python's datetime is so frustrating
While the focus will be on Swift and Cocoa, these issues apply to many languages and frameworks, and the same mistakes come up repeatedly. The focus will be on getting the right mental map for programming with calendars and time rather than a detailed syntax cookbook.
Thanks for the question. Updated to make the scope more clear.
What would this add over the API documentation in what you can fid on Stackoverflow?