Skip to content

Commit

Permalink
add a few more precisions on datetime fields and holes input ergonomics
Browse files Browse the repository at this point in the history
Signed-off-by: Stephen L. <lrq3000@gmail.com>
  • Loading branch information
lrq3000 committed Sep 4, 2022
1 parent a44ed84 commit ac746df
Showing 1 changed file with 6 additions and 4 deletions.
10 changes: 6 additions & 4 deletions docs/circalog-format-spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ The specification is intended as a working document for now, it is subject to ch

The database can be implemented in SQLite. The app should implement a native SQLite import/export/merge function, to natively support not only exports/backups but also imports and merging using a standard file format that is easy to load for post-processing data analysis. The export should be in a single file if possible, to ease exports and backups by non technical users (can easily be sent via e-mail). In the future, import/export in CSV or JSON may be possible but is not a priority. However, import from Sleepmeter CSV file format will be implemented.

Draft version: 0.7.3
Draft version: 0.7.4

## SQL relationships diagram

Expand Down Expand Up @@ -119,6 +119,8 @@ The number of columns should be kept at the minimal amount required to store val

Hence, all cosmetic information or parameters, such as subquestions labels, are saved in an `additional_fields` column, present in all tables to store both cosmetic information but also data that may be imported from other sleep diary programs that cannot be imported in another column, so as to not lose data when importing from different sleep diary file specifications.

All date, time and datetime fields should be [aware objects](https://docs.python.org/3/library/datetime.html#aware-and-naive-objects), with timezone information, to allow for unambiguous timestamping and comparison/conversion in other softwares/analytical scripts.

## Fields descriptions

### Table: event
Expand Down Expand Up @@ -149,11 +151,11 @@ Foreign key linking to `event_type`'s id. Defines what type of event this entry

#### start_time

Standard datetime format with timezone. Registers when time an event started, as defined by the user's inputs. Example for sleep: this is the fall asleep time. Mandatory. For special event types such as smartphone sensors (eg, light sensor, location), start_time is automatically set to the current time and cannot be modified.
Standard datetime format with timezone. Registers when time an event started, as defined by the user's inputs. Example for sleep: this is the fall asleep time. Mandatory. For special event types such as smartphone sensors (eg, light sensor, location), start_time is automatically set to the current time and cannot be modified. Default should be today, or last input datetime in the GUI if not closed since then, but do NOT try to guess a different start/end time for each new record, as Sleepmeter does, it's highly cumbersome and causes errors (ie, Sleepmeter considers that everytime we input a new record, it must be for the night before the current day or the last record inputted, so it will go backward for each new record by default).

#### end_time

Standard datetime format with timezone. Registers when time an event ended, as defined by the user's inputs. Example for sleep: this is the wake up time. Mandatory if event_type.punctual_or_duration_event == true, hidden otherwise.
Standard datetime format with timezone. Registers when time an event ended, as defined by the user's inputs. Example for sleep: this is the wake up time. Mandatory if event_type.punctual_or_duration_event == true, hidden otherwise. Do NOT try to guess from start date as Sleepmeter does, just let the user set the datetime as they wish without dynamical implicit changes that the user may miss, as Sleepmeter does (ie, changing start_time will change end_time but not in an intuitive way, and also the opposite can happen with the start_time changing when the user inputs a custom end_time!). Keep it simple stupid, just set by default the current datetime or last entered datetime if the app is still open since last inputted record, and then let the user select what they want, without any guesstimation.

#### pre_start_time

Expand All @@ -167,7 +169,7 @@ Standard datetime format with timezone. Registers the time at which user complet

String type of variable length, to store holes data: start from start_time (in minutes), duration (in minutes), and whether the hole was generated by tapping or manually created (true/false). Example: 10,30,1|60,5,0 represents two holes, the first starting 10min from the event's start_time and lasting 30min and was recorded by tapping (both start and end), after the pipe a second hole is represented at 1h past start_time, lasting for 5min and recorded manually (by the user opening the app and clicking on the Plus button without using tapping homescreen buttons). This will require a conversion from Sleepmeter's format, which represents the start and end of the hole relative to start_time, instead of start and duration of holes as done here.

Holes are very important to increase the accuracy of the sleep diary, of sleep fragmentation and of sleep duration, and it's much more convenient than linked sessions which is rather geared towards siestas or sleep sessions with a wide hole, but not lots of tiny holes. Also, it's easier to estimate the duration of a hole (eg, the user remembers waking up for about 10 minutes) than the exact timing when it happened ; actigraphy is better indicated for this purpose, but the goal here is to at least know there were fragmentations, not necessarily their exact timing, and it should be very easy for the user to input holes durations, regardless of the exact timing - to do so, Sleepmeter offers automatically dynamically guesstimated start and end times for manually added holes, but with more than 2 holes then it fails because it can only add holes after the previous ones, so we have to retime all the previous ones, 3 possible solutions for that: 1- we could allow the user to input holes durations without a start time for holes, the start time being optional (not the event's start_time, but the hole's!), 2- automatically reorder in chronological order the holes on save, so that the user does not have to manually modify each previously generated hole to add a new one that happened earlier than the others, 3- add an optional button to generate multiple holes uniformly spaced. We will likely implement solutions 1 and 2, they are the most elegant and flexible.
Holes are very important to increase the accuracy of the sleep diary, of sleep fragmentation and of sleep duration, and it's much more convenient than linked sessions which is rather geared towards siestas or sleep sessions with one or few wide holes, but not lots of tiny holes. Also, it's easier to estimate the duration of a hole (eg, the user remembers waking up for about 10 minutes) than the exact timing when it happened ; actigraphy is better indicated for this purpose, but the goal here is to at least know there were fragmentations, not necessarily their exact timing, and it should be very easy for the user to input holes durations, regardless of the exact timing - to do so, Sleepmeter offers automatically dynamically guesstimated start and end times for manually added holes, but with more than 2 holes then it fails because it can only add holes after the previous ones, so we have to retime all the previous ones, 3 possible solutions for that: 1- we could allow the user to input holes durations without a start time for holes, the start time being optional (not the event's start_time, but the hole's!), 2- automatically reorder in chronological order the holes on save, so that the user does not have to manually modify each previously generated hole to add a new one that happened earlier than the others, 3- add an optional button to generate multiple holes uniformly spaced. We will likely implement solutions 1 and 2, they are the most elegant and flexible. Also, a very easy ergonomical improvement over sleepmeter would be to allow to input holes in terms of sleep spans instead of holes spans, and both representations can be dynamically switched back and forth on GUI with simple calculations, ie, during a sleep session from 9:00 to 12:00 with a hole from 10:00 to 11:00, we could also input two sleep sessions from 9:00 to 10:00 and then 11:00 to 12:00. For irregular sleep patterns such as infants', the latter is much easier.

#### comment

Expand Down

0 comments on commit ac746df

Please sign in to comment.