{"id":31353,"date":"2021-01-18T15:48:33","date_gmt":"2021-01-18T20:48:33","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31353"},"modified":"2021-01-18T15:48:33","modified_gmt":"2021-01-18T20:48:33","slug":"storing-the-time-zone-with-a-date","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/01\/18\/storing-the-time-zone-with-a-date\/","title":{"rendered":"Storing the Time Zone With a Date"},"content":{"rendered":"

Harshil Shah<\/a> (tweet<\/a>):<\/p>\n

\n

Going back to how Date<\/code> works, 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 that Calendar<\/code> and DateFormatter<\/code> use.<\/p>\n

And as such, a Date<\/code> alone isn’t sufficient for modelling historical data, or at least personal historical data: You need time zone information too.<\/p>\n

HealthKit acknowledges this too. You do have the ability to specify a time zone when constructing the appropriate HKSample<\/code> subclass for the health data you’re modelling. It just so happens that while you are required to submit the start and end dates for any sample, the time zone information is entirely optional and buried within a metadata dictionary, that you can even omit entirely.<\/p>\n

All of the step data shown in the screenshot was captured by the Health app right on my phone, stored in HealthKit, and displayed by the Health app. Somewhere in this pipeline, the time zone information was ignored or discarded.<\/p>\n<\/blockquote>\n\n

Nick Lockwood<\/a>:<\/p>\n

I was just talking about this a few minutes ago, specifically the bad decision Apple made of having a default locale\/timezone in most of their date-related APIs, which helps to perpetuate the misconception that a Date object is a self-contained representation of a calendar date.<\/p><\/blockquote>\n\n

Previously:<\/p>\n