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.

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

[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

Conversation

gvaradarajan
Copy link
Member

No description provided.

@gvaradarajan gvaradarajan requested a review from a team as a code owner November 20, 2024 21:37
@@ -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?

Comment on lines +301 to +302
let tz = chrono_tz::Tz::UTC;
std::env::set_var("TZ", tz.name());
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

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?

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.

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

Comment on lines +16 to 18
use chrono::Datelike;
use chrono::Local;
use chrono::{format::ParseError, DateTime, FixedOffset};
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

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.

or the esp! macro to convert it to a result

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants