The use_night setting was replaced with the hours_before_first_measurement setting. This works with both the equidistant bucket generator as well as the daily bucket generator.
An export data request now only takes two parameters: first_measurement and number_of_days. The first_measurement is the date and time of the first measurement of the diary study for a user. For equidistant time intervals, the schedule for the measurements is derived by looking at the time of this measurement. The number of days is the number of days the user followed the diary study.
Only the exporter knows the start time and number of measurements for a user's diary study. The DataServices and bucket generator objects only know project global measurements_per_day, interval, and hours_before_first_measurement variables. The data ranges are captured using from and to arguments which are constructed by the exporter.
The from argument is the first time at which we want to start considering data points for this user. It is defined by the exporter as first_measurement - hours_before_first_measurement.hours. Note that this can fall on a previous day, which is fine. The to argument is the last time after which we stop considering data points. This is the time of the last measurement on the last day of the diary study of the user.
The methods that query the Google and Fitbit services receive the from and to arguments, and convert those either to dates or to nanosecond time offsets: either way they work to capture at least all and possibly more data than we are interested in. Possible data measurements that we receive from Google or Fitbit that we are not interested in (i.e., that occurred either before the from, after the to or during the night (which is defined by the engine global variable Physiqual.hours_before_first_measurement)) are discarded by the SummarizedDataService.
The SummarizedDataServices discards the extra measurements using extra information returned by the bucket generator. In addition to the end datetimestamp of each bucket, the bucket generator now also returns the start time for each bucket. This start time is defined as either the end time - hours_before_first_measurement for the first measurement of the day, or as the end time of the previous measurement on that day. This works with both the Equidistant bucket generator as well as the daily bucket generator. Having both the start and end ranges for each bucket, the SummarizedDataService now knows which data to discard. It also discards the extra bucket start time information so that its output is compatible with those of other data services.
frbl
commented
9 years ago
The
use_nightsetting was replaced with thehours_before_first_measurementsetting. This works with both the equidistant bucket generator as well as the daily bucket generator.An export data request now only takes two parameters:
first_measurementandnumber_of_days. The first_measurement is the date and time of the first measurement of the diary study for a user. For equidistant time intervals, the schedule for the measurements is derived by looking at the time of this measurement. The number of days is the number of days the user followed the diary study.Only the exporter knows the start time and number of measurements for a user's diary study. The DataServices and bucket generator objects only know project global measurements_per_day, interval, and hours_before_first_measurement variables. The data ranges are captured using
fromandtoarguments which are constructed by the exporter.The
fromargument is the first time at which we want to start considering data points for this user. It is defined by the exporter asfirst_measurement - hours_before_first_measurement.hours. Note that this can fall on a previous day, which is fine. Thetoargument is the last time after which we stop considering data points. This is the time of the last measurement on the last day of the diary study of the user.The methods that query the Google and Fitbit services receive the
fromandtoarguments, and convert those either to dates or to nanosecond time offsets: either way they work to capture at least all and possibly more data than we are interested in. Possible data measurements that we receive from Google or Fitbit that we are not interested in (i.e., that occurred either before thefrom, after thetoor during the night (which is defined by the engine global variablePhysiqual.hours_before_first_measurement)) are discarded by the SummarizedDataService.The SummarizedDataServices discards the extra measurements using extra information returned by the bucket generator. In addition to the end datetimestamp of each bucket, the bucket generator now also returns the start time for each bucket. This start time is defined as either the end time - hours_before_first_measurement for the first measurement of the day, or as the end time of the previous measurement on that day. This works with both the Equidistant bucket generator as well as the daily bucket generator. Having both the start and end ranges for each bucket, the SummarizedDataService now knows which data to discard. It also discards the extra bucket start time information so that its output is compatible with those of other data services.