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

feat: respect /etc/timezone, /etc/localtime, TZ like ls and exa does #653

Open
fox91 opened this issue Nov 13, 2023 · 7 comments
Open

feat: respect /etc/timezone, /etc/localtime, TZ like ls and exa does #653

fox91 opened this issue Nov 13, 2023 · 7 comments
Labels
errors Something isn't working

Comments

@fox91
Copy link

fox91 commented Nov 13, 2023 •
edited
Loading

Being used to the ls output and having used exa which reproduced it (in my opinion) correctly, I believe there is a bug in the eza output.
In the examples below you can see how the modification date of the baz file is shown differently in eza, as if it did not take into account the daylight savings time changes during the year.
The time that is shown is not incorrect, it is simply shown in the current timezone (UTC+1) instead of taking into account the time changes present in the selected timezone (Europe/Rome in this case).

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

$ uname -a
Linux pcname 5.4.0-166-generic #183-Ubuntu SMP Mon Oct 2 11:28:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/timezone 
Europe/Rome

$ ls --version
ls (GNU coreutils) 8.30

$ ls -lAF --full-time
total 0
-rw-r--r-- 1 user group 0 2023-02-04 10:35:00.000000000 +0100 bar
-rw-r--r-- 1 user group 0 2023-06-04 10:35:00.000000000 +0200 baz
-rw-r--r-- 1 user group 0 2023-11-12 10:35:00.000000000 +0100 foo

$ exa --version
v0.10.1 [+git]

$ exa -aglF --time-style full-iso
.rw-r--r-- 0 user group 2023-02-04 10:35:00.000000000 +0100 bar
.rw-r--r-- 0 user group 2023-06-04 10:35:00.000000000 +0200 baz
.rw-r--r-- 0 user group 2023-11-12 10:35:00.000000000 +0100 foo

$ eza --version
v0.15.3 [+git]

$ eza -aglF --time-style full-iso
.rw-r--r-- 0 user group 2023-02-04 10:35:00.000000000 +0100 bar
.rw-r--r-- 0 user group 2023-06-04 09:35:00.000000000 +0100 baz
.rw-r--r-- 0 user group 2023-11-12 10:35:00.000000000 +0100 foo
@fox91 fox91 added the errors Something isn't working label Nov 13, 2023
@cafkafk cafkafk changed the title bug: Strange behavior after the daylight savings time change feat: respect /etc/timezone Nov 13, 2023
@9glenda
Copy link
Member

9glenda commented Nov 13, 2023 •
edited
Loading

Eza should also be able to read from the TZ variable like Firefox for example does.
I'm not sure about rather /etc/timezone is the right place for this. I'd much prefer /etc/localtime. NixOS for example hat no /etc/timezone iirc.

Example usage for /etc/localtime

zdump /etc/localtime

freedesktop reference

Note

This is a systemd thing so maybe we want non systemd support

https://www.freedesktop.org/software/systemd/man/latest/localtime.html

@fox91
Copy link
Author

fox91 commented Nov 13, 2023 •
edited
Loading

On Ubuntu there are both /etc/timezone and /etc/localtime, both valued with Europe/Rome (on my system).
I know about the TZ variable and I tried to use it but the result doesn't change (that's why I didn't include it in the original issue).

$ TZ=UTC eza -aglF --time-style full-iso
.rw-r--r-- 0 user group 2023-02-04 09:35:00.000000000 +0000 bar
.rw-r--r-- 0 user group 2023-06-04 08:35:00.000000000 +0000 baz
.rw-r--r-- 0 user group 2023-11-12 09:35:00.000000000 +0000 foo

$ TZ=Europe/Berlin eza -aglF --time-style full-iso
.rw-r--r-- 0 user group 2023-02-04 10:35:00.000000000 +0100 bar
.rw-r--r-- 0 user group 2023-06-04 09:35:00.000000000 +0100 baz
.rw-r--r-- 0 user group 2023-11-12 10:35:00.000000000 +0100 foo

TZ is used by eza but not correctly: it seems that the current offset is used throughout the year.
With the same TZ values ls and exa behave correctly.

In macOS Sonoma (14.1.1), which does not have /etc/timezone but only /etc/localtime, there is the same problem, same thing using TZ while both ls and exa works.

@fox91 fox91 changed the title feat: respect /etc/timezone feat: respect /etc/timezone, /etc/localtime, TZ like ls and exa does Nov 13, 2023
@cafkafk
Copy link
Member

cafkafk commented Nov 14, 2023

Interestingly for me on eza v0.15.1 on NixOS:

❯ zdump /etc/localtime
/etc/localtime  Tue Nov 14 07:07:15 2023 CET
❯ eza -l testfile
.rw-r--r-- 0 ces 14 Nov 07:07 testfile
❯ eza -laglF --time-style full-iso testfile
.rw-r--r-- 0 ces users 2023-11-14 07:07:52.788969315 +0100 testfile
❯ echo "modification" >> testfile
❯ eza -laglF --time-style full-iso testfile
.rw-r--r-- 13 ces users 2023-11-14 07:09:53.656705263 +0100 testfile

@fox91
Copy link
Author

fox91 commented Nov 14, 2023

Interestingly for me on eza v0.15.1 on NixOS:

Can you try with:

touch -d "2023-02-04 10:35:00" bar
touch -d "2023-06-04 10:35:00" baz
touch -d "2023-11-12 10:35:00" foo

TZ=Europe/Berlin eza -aglF --time-style full-iso bar baz foo

@cafkafk
Copy link
Member

cafkafk commented Nov 16, 2023 

~/tz 
✦ ❯ touch -d "2023-02-04 10:35:00" bar

~/tz 
✦ ❯ touch -d "2023-06-04 10:35:00" baz

~/tz 
✦ ❯ touch -d "2023-11-12 10:35:00" foo

~/tz 
✦ ❯ TZ=Europe/Berlin eza -aglF --time-style full-iso bar baz foo
.rw-r--r-- 0 ces users 2023-02-04 10:35:00.000000000 +0100 bar
.rw-r--r-- 0 ces users 2023-06-04 09:35:00.000000000 +0100 baz
.rw-r--r-- 0 ces users 2023-11-12 10:35:00.000000000 +0100 foo

~/tz 
✦ ❯ eza -aglF --time-style full-iso bar baz foo
.rw-r--r-- 0 ces users 2023-02-04 10:35:00.000000000 +0100 bar
.rw-r--r-- 0 ces users 2023-06-04 09:35:00.000000000 +0100 baz
.rw-r--r-- 0 ces users 2023-11-12 10:35:00.000000000 +0100 foo

Can reproduce.

@erwinvaneijk
Copy link
Contributor

The issue at hand here, seems to be that eza sets the time_offset once in the environment (output/table.rs: 351), after which it is used everywhere. However, most timezones have daylight saving time, and when that applied at the time of the timestamp, have that offset used.

erwinvaneijk added a commit to erwinvaneijk/eza that referenced this issue Dec 9, 2023
@erwinvaneijk
feat(localtime): make full iso display correct timezone
89c74a4 
When a file was created under a daylight saving time, and when the
computer rendering that timestamp wasn't the incorrect timestamp was
shown.

This fixes issue eza-community#653.
erwinvaneijk added a commit to erwinvaneijk/eza that referenced this issue Dec 9, 2023
@erwinvaneijk
feat(time display): time display use /etc/timezone
39c18ac 
When a file timestamp is updated under daylight saving time, and
displayed when it is not, the wrong time offset is displayed (and vice
versa).

Fixes issue eza-community#653.
@erwinvaneijk erwinvaneijk mentioned this issue Dec 9, 2023
Closed
erwinvaneijk added a commit to erwinvaneijk/eza that referenced this issue Dec 12, 2023
@erwinvaneijk
feat(time): time display use /etc/timezone
d18c007 
When a file timestamp is updated under daylight saving time, and
displayed when it is not, the wrong time offset is displayed (and vice
versa).

Fixes issue eza-community#653.
@IzhakJakov
Copy link

IzhakJakov commented Feb 13, 2024 •
edited
Loading

I think this is similar to the issue I am having:

 ❯ touch -t 202110221528.27 development-values.yaml

 ❯ eza --long --time-style=long-iso development-values.yaml
.rw-r--r--@ 73 jizhak 2021-10-22 14:28 development-values.yaml

 ❯ ls --time-style='+%Y-%m-%d %H:%M' -l development-values.yaml
-rw-r--r-- 1 jizhak staff 73 2021-10-22 15:28 development-values.yaml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
errors Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fox91 @erwinvaneijk @IzhakJakov @9glenda @cafkafk