-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
date: improve timezone handling and UTC mode support #7597
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
base: main
Are you sure you want to change the base?
Conversation
GNU testsuite comparison:
|
Can you please run |
2de96bd
to
5792dd7
Compare
Done and Thanks. |
GNU testsuite comparison:
|
@@ -492,3 +492,101 @@ fn test_date_empty_tz() { | |||
.succeeds() | |||
.stdout_only("UTC\n"); | |||
} | |||
|
|||
#[test] | |||
fn test_date_tz_utc() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you do a blank TZ too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comments. there was one test empty TZ and I add another one with .arg("@0")
as an additional test.
.arg("+%Z") | ||
.succeeds() | ||
.stdout_only("UTC\n"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it'd be nice to have tests that actually test that the output time is shifted properly (since that's the issue in #7498). You should pass a fixed datetime as a parameter to date
and check that the output is exactly what you expect.
Note that adding a full test for #7498 might be tricky, as it sort of relies on the localtime not being UTC (not sure how our CI runners are configured...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dear @drinkcat , I've added a test for this but it was not working correctly on CI/CD. Its kind of complicated. Will try again tomorrow.
Side note: I also did minor changes to other tests to respect the Day Light Saving changes.
330bb67
to
7184adc
Compare
Side note: it seems our |
GNU testsuite comparison:
|
- Add proper UTC mode handling with -u flag - Improve TZ environment variable support - Add more TZ tests FIXES uutils#7497 FIXES uutils#7498
GNU testsuite comparison:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, started looking at other timezone stuff and realized this was pending.
Still not 100% sure to understand everything, trying to simplify things where possible.
@@ -273,7 +294,13 @@ pub fn uumain(args: impl uucore::Args) -> UResult<()> { | |||
for date in dates { | |||
match date { | |||
Ok(date) => { | |||
let format_string = custom_time_format(format_string); | |||
let format_string = if should_use_utc(settings.utc) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to move that logic to custom_time_format
?
/// Check if we should use UTC time based on the utc flag and TZ environment variable | ||
fn should_use_utc(utc: bool) -> bool { | ||
// Either the -u flag is set or the TZ environment variable is empty | ||
utc || matches!(std::env::var("TZ"), Ok(tz) if tz.is_empty()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this is slightly nicer: std::env::var("TZ").is_ok_and(|tz| tz.is_empty())
@@ -167,7 +185,7 @@ pub fn uumain(args: impl uucore::Args) -> UResult<()> { | |||
}; | |||
|
|||
let date_source = if let Some(date) = matches.get_one::<String>(OPT_DATE) { | |||
let ref_time = Local::now(); | |||
let ref_time = get_current_time(matches.get_flag(OPT_UNIVERSAL)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have a mild preference if you did this:
let utc = matches.get_flag(OPT_UNIVERSAL);
And used utc here and below when initializing settings
.
now.with_timezone(&now.offset().fix()) | ||
let now = get_current_time(settings.utc); | ||
// Convert to FixedOffset for consistent timezone handling | ||
let now_fixed = if should_use_utc(settings.utc) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't you moving the now_fixed
logic into get_current_time
? Seems like you output something with the wrong timezone in get_current_time
that you now need to adjust again?
@jadijadi looking at this a bit more... I feel like this would be better fixed in See chronotope/chrono#1690 . If you're interested to submit a patch for chrono I'm happy to leave it to you, just let me know. If we have problems getting this fix into chrono (or if getting a new release takes time), we could think of some wrapper in uucore that fixes this for all the apps that handle dates (not just |
Argh, maybe I'm wrong, I think we still need some custom logic to handle timezone passed in But... I think we can make things easier by having a wrapper function that returns something like this:
(where tz comes from the code we already have in |
@jadijadi are you still working on it ? thanks :) |
(btw the empty |
yes. had a busy week. will work on it during this long weekend |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waiting for update
I'm a bit lost on this. As @drinkcat mentioned, its better to have most of these fixes in I'm still having busy work days and wont have time to go deeper and see what is changed in upcomming days. If anyone else wants to finish this, I will be happy. |
I... also lost all context... and if it's not clear from my comments, I was also a bit confused a few weeks ago when I tried to look at this ,-)
|
iana_time_zone::get_timezone doesn't cover all cases, so we need to handle some of the timezone parsing manually. Also add a bunch of TODO, this function is by no means complete. (change similar to uutils#7597 for this file)
iana_time_zone::get_timezone doesn't cover all cases, so we need to handle some of the timezone parsing manually. Also add a bunch of TODO, this function is by no means complete. (change similar to uutils#7597 for this file)
iana_time_zone::get_timezone doesn't cover all cases, so we need to handle some of the timezone parsing manually. Also add a bunch of TODO, this function is by no means complete. (change similar to uutils#7597 for this file)
iana_time_zone::get_timezone doesn't cover all cases, so we need to handle some of the timezone parsing manually. Also add a bunch of TODO, this function is by no means complete. (change similar to uutils#7597 for this file)
FIXES #7497
FIXES #7498