Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[RSDK-9226] - fix time of day not setting when starting offline #352

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[RSDK-9226] - fix time of day not setting when starting offline #352

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions micro-rdk/src/common/app_client.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,8 @@ use crate::proto::{
},
};
use bytes::{BufMut, Bytes, BytesMut};
use chrono::Datelike;
use chrono::Local;
use chrono::{format::ParseError, DateTime, FixedOffset};
Comment on lines +16 to 18
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add these to existing import

use futures_lite::{Future, StreamExt};
use http_body_util::BodyExt;
Expand Down Expand Up @@ -284,6 +286,37 @@ impl AppClient {
} else {
None
};

#[cfg(feature = "esp32")]
{
// If the current datetime has not already been set, we use the datetime from
// the config response to set the time of day on the device. This may be replaced
// by calls to an NTP server in the future
let local_dt = Local::now().fixed_offset();
// Viam does not pre-exist the year 2020, so if the year is before that
// at the very least the current time is wrong and needs to be corrected
if local_dt.year() < 2020 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This value is now referenced in two places that need to remain in sync, should we ever decide to change it. Let's make a constant for it.

if let Some(current_dt) = datetime {
use esp_idf_svc::sys::{settimeofday, timeval};
let tz = chrono_tz::Tz::UTC;
std::env::set_var("TZ", tz.name());
Comment on lines +301 to +302
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • We probably should only be doing the env var set once, at startup. Also not clear to me that it is safe for us to be calling it at all, as an MT program:
In multi-threaded programs on other operating systems, the only safe option is to not use set_var or remove_var at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scrolling down on that page, it looks like tzset is only necessary for older versions of Newlib? It was working before without it, so I'd be a little surprised that we suddenly need it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see anything further about tzset w.r.t. newlib on that page. Could you quote it?

let tv_sec = current_dt.timestamp() as i32;
let tv_usec = current_dt.timestamp_subsec_micros() as i32;
let current_timeval = timeval { tv_sec, tv_usec };
let res = unsafe {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't really need res right?

if unsafe {...} != 0 { log::error!... ought to do

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or the esp! macro to convert it to a result

settimeofday(&current_timeval as *const timeval, std::ptr::null())
};
if res != 0 {
log::error!(
"could not set time of day for timezone {:?} and timestamp {:?}",
tz.name(),
current_dt
);
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine to defer this into a new ticket, but should we consider calling adjtime if we have a good local datetime but it differs from what app is telling us?

}

if r.is_empty() {
return Err(AppClientError::AppClientEmptyBody);
}
Expand Down
24 changes: 0 additions & 24 deletions micro-rdk/src/common/conn/viam.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -486,30 +486,6 @@ where
.ok(),
None => None,
};
#[cfg(feature = "esp32")]
{
use esp_idf_svc::sys::{settimeofday, timeval};
let _ = config.as_ref().is_some_and(|cfg| {
cfg.1.is_some_and(|current_dt| {
let tz = chrono_tz::Tz::UTC;
std::env::set_var("TZ", tz.name());
let tv_sec = current_dt.timestamp() as i32;
let tv_usec = current_dt.timestamp_subsec_micros() as i32;
let current_timeval = timeval { tv_sec, tv_usec };
let res = unsafe {
settimeofday(&current_timeval as *const timeval, std::ptr::null())
};
if res != 0 {
log::error!(
"could not set time of day for timezone {:?} and timestamp {:?}",
tz.name(),
current_dt
);
}
true
})
});
}

let (config, build_time) = config.map_or_else(
|| {
Expand Down
2 changes: 1 addition & 1 deletion micro-rdk/src/common/data_manager.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -520,7 +520,7 @@ where
Ok(data) => data,
Err(DataSyncError::NoCurrentTime) => {
log::error!("Could not calculate data timestamps, returning without flushing store");
return Ok(());
continue;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this right? I think the idea of returning out of run here is that if you didn't have enough info to calculate timestamps now, why would you move on to the next collector, which will just fail the same way? Instead, bail out of run and hope that the next time run is queued up by invoke that the situation has improved. As written with continue, won't this just result in the repeated logging of Could not calculate data timestamps, returning without flushing store, once for each configured collector, and then returning anyway?

}
Err(err) => {
log::error!(
Expand Down
Loading