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

[fox91]

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

[9glenda]

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]

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.

[cafkafk]

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]

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]

~/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]

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.

[IzhakJakov]

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