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

friederbluemle opened this issue Mar 1, 2020 · 3 comments

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

friederbluemle opened this issue Mar 1, 2020 · 3 comments


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). ;)

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
    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);


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.

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.

Copy link

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
None yet
None yet

No branches or pull requests

3 participants