Helping you navigate the insane complexity of calendrically correct date and time operations
The key take away from all these stats are:
DateFormatteris expensive to create.DateFormatteris expensive to change.- Subsequent use of
string(from: Date)is cheap.- Subsequent use of
date(from: String)is not cheap.
This is slightly misleading, though. Despite what the preview shows,
Datehas no concept of days, months, years, any of that stuff. It deals solely with time, and more specifically, the number of seconds that have passed since midnight of 1 January 2001, in UTC.[...]
Here’s a screenshot from the Health app, showing my step counts for the day of June 8, 2017. It was a fairly active day, as I got in a bit over 20,000 steps. The distribution of those steps, though, feels a bit off. It reads like I was up walking all night, and then asleep throughout the day, and scrolling around a bit, that’s the story for the rest of the week too. I don’t remember spending the week that way.
As it happens I was in San Jose attending WWDC at the time, which has a -12:30 time difference with India , and as a result all of my health data from that trip appears time-shifted.
[...]
Going back to how
Dateworks, it doesn’t model the actual clock time but rather a fixed point in time that can be interpreted in any time zone. And so what’s happening here is that the data is being interpreted as if it happened in my current time zone, which is the default time zone thatCalendarandDateFormatteruse.And as such, a
Datealone isn’t sufficient for modelling historical data, or at least personal historical data: You need time zone information too.
Parsing fixed-format date strings is tricky. For an explanation as to why, see QA1480 NSDateFormatter and Internet Dates. However, there’s an extra gotcha when you try to parse fixed-format date strings that don’t include a time.