Question: What's (in) a day?

I’ve stumbled over this before, but most recently when I was thinking about the hearing sensitivity over the day question: What is a day? The question might sound a bit stupid, but specifically it’s about what is the proper unit for doing analysis where we want to look at things where we assume that they change throughout the day?

The default for many things is using the calendar day and most apps also store their data that way. Plus plotting data is a whole lot easier if one sticks to calendar days, as virtually every plotting tool can handle that out of the box. At the same time that feels rather unintuitive to me, while the ‘waking period’ makes more sense to me. After all, my body doesn’t magically reset at midnight and I virtually never go to bed before midnight, usually having a non-trivial amount of being awake on the following calendar day.

The Oura Ring actually solves this issue quite nicely I think. E.g. steps taken, calories burned etc. are all counted for the current wake period, and the wake period itself is saved according to the day during which you woke up (that last bit is iirc). This allows the data to reflect the lived experience a bit better than just sticking to the calendar.

If one uses a sleep tracker it’s possible to correct most data this way (if it’s properly stored in intraday intervals), but it’s somewhat of a pain to correct for this. Has anyone figured out a somewhat automated solution to this problem? Or is the idea of correcting for this not great for some reason I’m missing?

1 Like

Good question, and I don’t have an easy answer. Waking period is fine, but what do you do about naps? And time zones mess with everything: how do you handle the definition of a “day” when you are flying internationally.

I tend to revert back to using UTC-compatible timestamps for everything. This postpones the problem to the analysis stage, where the answer to ‘what is a day’ depends on what you’re trying to study.

Oura does handle napping inside the day as rest period iirc (probably based around timing of the sleep and duration). But it’s indeed a potential issue.

Time zone changes are always a pain indeed, and there’s no simple way to deal with them. But yes, using UTC-based time stamps are great, but attaching the correct time zone becomes somewhat trivial if one does geolocation tracking in parallel. Also: some tools properly store the time zone recorded, so converting to UTC is always a possibility.

Generally, I wonder about whether there’s any best practices to solve the issue during the analysis stage in an elegant way :wink: