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.

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

Leap year bug - Feb 29 shows as Mar 1 #638

Closed
friederbluemle opened this issue Mar 1, 2020 · 3 comments
Closed

Leap year bug - Feb 29 shows as Mar 1 #638

friederbluemle opened this issue Mar 1, 2020 · 3 comments

Comments

@friederbluemle
Copy link

friederbluemle commented Mar 1, 2020

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
Copy link

DrJackilD commented Mar 22, 2020

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
Copy link

DrJackilD commented Mar 22, 2020

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.

@ariasuni
Copy link
Collaborator

ariasuni commented Jan 13, 2021

This was fixed by updating the datetime crate in da1ac51, there just hasn’t been a new release made since then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants