Drop DateTimeTz from FitnessTrax #131

Merged
savanni merged 1 commits from fitnesstrax/drop-datetimetz into main 2023-12-28 17:52:18 +00:00
4 changed files with 21 additions and 50 deletions
Showing only changes of commit e30668ca8e - Show all commits

View File

@ -23,7 +23,6 @@ use async_channel::Sender;
use chrono::{NaiveDate, TimeZone};
use chrono_tz::America::Anchorage;
use dimensioned::si::{KG, M, S};
use emseries::DateTimeTz;
use ft_core::{Steps, TimeDistance, TraxRecord, Weight};
use gio::resources_lookup_data;
use gtk::STYLE_PROVIDER_PRIORITY_USER;
@ -149,39 +148,7 @@ impl AppWindow {
})
.upcast(),
),
ViewName::Historical => View::Historical(
HistoricalView::new(vec![
TraxRecord::Steps(Steps {
date: NaiveDate::from_ymd_opt(2023, 10, 13).unwrap(),
count: 1500,
}),
TraxRecord::Weight(Weight {
date: NaiveDate::from_ymd_opt(2023, 10, 13).unwrap(),
weight: 85. * KG,
}),
TraxRecord::Weight(Weight {
date: NaiveDate::from_ymd_opt(2023, 10, 14).unwrap(),
weight: 86. * KG,
}),
TraxRecord::BikeRide(TimeDistance {
datetime: DateTimeTz(
Anchorage.with_ymd_and_hms(2019, 6, 15, 12, 0, 0).unwrap(),
),
distance: Some(1000. * M),
duration: Some(150. * S),
comments: Some("Test Comments".to_owned()),
}),
TraxRecord::BikeRide(TimeDistance {
datetime: DateTimeTz(
Anchorage.with_ymd_and_hms(2019, 6, 15, 23, 0, 0).unwrap(),
),
distance: Some(1000. * M),
duration: Some(150. * S),
comments: Some("Test Comments".to_owned()),
}),
])
.upcast(),
),
ViewName::Historical => View::Historical(HistoricalView::new(vec![]).upcast()),
}
}
}

View File

@ -151,7 +151,7 @@ impl From<Vec<TraxRecord>> for GroupedRecords {
.into_iter()
.fold(HashMap::new(), |mut acc, rec| {
let date = match rec.timestamp() {
Timestamp::DateTime(dtz) => dtz.0.date_naive(),
Timestamp::DateTime(dtz) => dtz.date_naive(),
Timestamp::Date(date) => date,
};
acc.entry(date)
@ -169,10 +169,10 @@ impl From<Vec<TraxRecord>> for GroupedRecords {
#[cfg(test)]
mod test {
use super::GroupedRecords;
use chrono::{NaiveDate, TimeZone};
use chrono::{FixedOffset, NaiveDate, TimeZone};
use chrono_tz::America::Anchorage;
use dimensioned::si::{KG, M, S};
use emseries::DateTimeTz;
use emseries::{Record, RecordId};
use ft_core::{Steps, TimeDistance, TraxRecord, Weight};
#[test]
@ -191,13 +191,19 @@ mod test {
weight: 86. * KG,
}),
TraxRecord::BikeRide(TimeDistance {
datetime: DateTimeTz(Anchorage.with_ymd_and_hms(2019, 6, 15, 12, 0, 0).unwrap()),
datetime: FixedOffset::west_opt(10 * 60 * 60)
.unwrap()
.with_ymd_and_hms(2019, 6, 15, 12, 0, 0)
.unwrap(),
distance: Some(1000. * M),
duration: Some(150. * S),
comments: Some("Test Comments".to_owned()),
}),
TraxRecord::BikeRide(TimeDistance {
datetime: DateTimeTz(Anchorage.with_ymd_and_hms(2019, 6, 15, 23, 0, 0).unwrap()),
datetime: FixedOffset::west_opt(10 * 60 * 60)
.unwrap()
.with_ymd_and_hms(2019, 6, 15, 23, 0, 0)
.unwrap(),
distance: Some(1000. * M),
duration: Some(150. * S),
comments: Some("Test Comments".to_owned()),

View File

@ -1,7 +1,3 @@
use chrono::NaiveDate;
use dimensioned::si;
use emseries::DateTimeTz;
mod legacy;
mod types;
pub use types::{Steps, TimeDistance, TraxRecord, Weight};

View File

@ -1,6 +1,6 @@
use chrono::NaiveDate;
use chrono::{DateTime, FixedOffset, NaiveDate};
use dimensioned::si;
use emseries::{DateTimeTz, Recordable, Timestamp};
use emseries::{Recordable, Timestamp};
use serde::{Deserialize, Serialize};
/// SetRep represents workouts like pushups or situps, which involve doing a "set" of a number of
@ -30,11 +30,13 @@ pub struct Steps {
#[derive(Clone, Debug, PartialEq, Serialize, Deserialize)]
pub struct TimeDistance {
/// The precise time (and the relevant timezone) of the workout. One of the edge cases that I
/// account for is that a ride which occurred at 11pm in one timezone would then count as 1am
/// if one moved two timezones to the east. This is kind of nonsensical from a human
/// perspective, so the DateTimeTz keeps track of the precise time in UTC, but also the
/// timezone in which the event was recorded.
pub datetime: DateTimeTz,
/// account for is that a ride which occurred at 11pm on one day in one timezone would then
/// count as 1am on the next day if the user moves two timezones to the east. While technically
/// correct, for most users this would throw off many years of metrics in ways that can be very
/// hard to understand. Keeping the fixed offset means that we can have the most precise time
/// in the database, but we can still get a Naive Date from the DateTime, which will still read
/// as the original day.
pub datetime: DateTime<FixedOffset>,
/// The distance travelled. This is optional because such a workout makes sense even without
/// the distance.
pub distance: Option<si::Meter<f64>>,