Exa: Leap year bug - Feb 29 shows as Mar 1

[friederbluemle]

Today is February 29, 2020 (a leap day), and exa incorrectly displays today's date as Mar 1:

$ touch test
$ exa -l test
.rw-r--r-- 0 fb  1 Mar 16:57 test
$ ls -l test
-rw-r--r--  1 fb  staff  0 Feb 29 16:57 test

EDIT: I just found #101 from four years ago 😄 I guess the eventual fix should fix both issues at the same time (or we can close this one). ;)

[DrJackilD]

Looks like this problem related to datetime crait. Look at this comparison between chrono and datetime:

use chrono::NaiveDateTime;
use datetime::LocalDateTime;
use std::fs::File;
use std::time::UNIX_EPOCH;

fn main() {
    let f = File::open("feb29_file").unwrap();
    let accessed = f
        .metadata()
        .unwrap()
        .accessed()
        .unwrap()
        .duration_since(UNIX_EPOCH)
        .unwrap();
    println!("Ts: {}", accessed.as_secs() as i64);
    let datetime_dt = LocalDateTime::at(accessed.as_secs() as i64);
    let chrono_dt = NaiveDateTime::from_timestamp(accessed.as_secs() as i64, 0);
    println!("datetime: {:#?}", datetime_dt);
    println!("chrono: {}", chrono_dt);
}

Output:

Ts: 1582975800
datetime: LocalDateTime(2020-03-01T11:30:00.000)
chrono: 2020-02-29 11:30:00

Good news, it's not related to Rust core (fs ot time) and just a problem of converting from Unix Epoch to some meaningful datetime representation.

I think I could take a task to migrate from datetime to chrono or other datetime library, if maintainers consider this worth it.

[DrJackilD]

Actually, looks like datetime maintainer fix this bug already (commit). I can confirm, that master branch of datetime works correctly now. Anyway, I don't see any releases till 0.4.7 which still has this bug.