feat(time_display): time should use timezone settings #1327
Conversation
When a file timestamp is displayed, it should use the timezone info from the time of the timestamp, not from when it is displayed. This occurs when a file timestamp is updated under daylight saving time, and displayed at a time when not under daylight saving time. This bug is quite subtle, as it depends on the time of construction of the timestamp, not on the moment it is read.
erwinvaneijk
force-pushed
the
issue-653-2
branch
from
6bcd549 to
efe1577
Compare
- lifetimes that can be elided - not use return as last statement in function
erwinvaneijk
requested review from
MartinFillon,
PThorpe92 and
gierens
as code owners
|
The pipeline is still not happy. I think another |
Yes, go a bit annoyed because only FreeBSD tests failed (different rustc settings?), and after some to-and-from work, I've forgotten to run |
|
Yea, I hear ya. I've run into BSD related issues myself. And don't get me started on illumos pipelines. No project should ever use those. Argh! |
|
But, all tests pass! Yeah! @cafkafk it's ready for review and/or merge. |
src/output/render/times.rs
Outdated
| let datestamp = if let Some(time) = self { | ||
| fn render(self, style: Style, time_format: TimeFormat) -> TextCell { | ||
| let datestamp = if let Ok(timezone_str) = iana_time_zone::get_timezone() { | ||
| let timezone: chrono_tz::Tz = timezone_str.parse().unwrap(); |
There was a problem hiding this comment.
I guess we can, it feels like a good default.
There was a problem hiding this comment.
That works, tests pass on my machine. Let's wait for the GH actions to pass.
There was a problem hiding this comment.
@PThorpe92 In theory I agree with not using unwrap, but in this case it actually might make sense.
If the TZ cannot be parsed, something is off. This should be looked into.
But now the issue is silently ignored and a TZ is set without notifying the user. Additionally a "wrong" datetime is presented and since the user doesn't know that eza just picked UTC, it will be even more confusing.
I'd opt for either using expect with a proper message, or using UTC as you suggested but output a warning to the user.
P.S: In case you really want this behavior, there's no need to use the Etc module. UTC is a constant and can be used as Tz::UTC or since nothing was used before chrono_tz::Tz::UTC. I would rather use use chrono_tz::Tz; and then use let timezone: Tz = timezone_str.parse().unwrap_or(Tz::UTC);
There was a problem hiding this comment.
I agree, it would be really weird if iana_time_zone comes up with something that cannot be parsed into a timezone. I've changed the unwrap_or to an expect, per your suggestion.
There was a problem hiding this comment.
I don't have a binding vote on design issues, but I only brought it up as a point for discussion. Ultimately the eza devs will have to decide how to handle this.
There was a problem hiding this comment.
I know, and I agree that the devs have the last saying, but I also agree that in this case not using a default but writing out that something really weird is going on is the better option.
There was a problem hiding this comment.
And, I found out if you want to have a useful error message, with a function in it, then you can't use expect, but you have to use unwrap_or_else.
There was a problem hiding this comment.
expect also panics, it just does so with a proper message. The "warning" to the user I mentioned might be more complicated to achieve depending on the code, error propagation, and warning implementations. I haven't checked. unwrap_or_else should work, but I can't say whether it conforms to the rest of the code...
I'd wait for @PThorpe92's input.
When an invalid timezone string is obtained, which is really unexpected, we write out a message saying so, instead of using a sensible default.
Changed the`expect` for an `unwrap_or_else` to make clippy happy and have descriptive error message.
Clippy wants inline variables in a `format!`.
There was a problem hiding this comment.
Nice catch! Generally LGTM! Thanks!
The only two things I think could be improved are:
- Most of the commit messages are understandable in the context of this PR but maybe a bit too general for this to be still the case after rebase/merge when this is part of the wider history. So adding scopes and being a little more precise and adding context would help.
- Some of the small fix commits might be better of either squashed together or into the commits that caused them.
|
I cannot speak for @erwinvaneijk but in my projects I don't care about the commit messages in a PR. What is important is that you don't do a merge commit, but rather a squash commit - and then use a convential commit message. This means that the person who merges the PR can pick whatever commit message they want and there will be only one commit. P.S.: Previously I asked people to rebase, squash, force push in PRs, but I no longer do that. It's easier to follow the development of the PR if this is not done. Especially when there are a lot of comments and change requests. |
|
Glad you like the PR @gierens, thank you for the review. However, the changes you request to the commit messages cannot be done (or my That goes for me too. The merge to the main should be well-formatted, and it's a choice whether or not to squash or just merge. Trying to create a squash merge in this PR that then can be merged is a pain, IMNSHO. |
When a file timestamp is displayed, it should use the timezone info from the time of the timestamp, not from when it is displayed. This occurs when a file timestamp is updated under daylight saving time, and displayed at a time when not under daylight saving time.
The bug is quite subtle, as it depends on the time of construction of the timestamp, not on the moment it is read.
This fixes issue #653 .