Due to Logcat entries not including the year, it's currently assumed to be the current year:
https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/android.rs#L263
That's a problem in a few edge cases:
- If the log spans multiple years (e.g. December 31 to January 1)—the year for each entry should be guessed separately;
- If, for example, the log was taken on December 31 but viewed next year on January 1—perhaps it'd be better to get the year from the timestamp in the information section.
Maybe it's better to remove the year altogether, so that the app doesn't show wrong information. In that case, creating a date object should probably use a hardcoded year that includes February 29 (are there any other considerations that need to be made?), and after converting it to a string, remove the year.
Due to Logcat entries not including the year, it's currently assumed to be the current year:
https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/android.rs#L263
That's a problem in a few edge cases:
Maybe it's better to remove the year altogether, so that the app doesn't show wrong information. In that case, creating a date object should probably use a hardcoded year that includes February 29 (are there any other considerations that need to be made?), and after converting it to a string, remove the year.