Skip to content

Conversation

@anaboccanfuso
Copy link

What do these changes do?

Fixes an issue in the parse_ls_date function where dates more than half a year in the past were incorrectly showing up with next year's date.

The original code was using HALF_OF_YEAR_IN_SECONDS to determine if a date should be adjusted to the next year, which caused January dates to incorrectly show up as 2026 instead of 2025 when the current date is in August 2025.

The fix:

  1. Removes the dependency on HALF_OF_YEAR_IN_SECONDS
  2. Changes the date parsing logic to use the current year by default
  3. Only adjusts the year to the previous year if the resulting date would be
    in the future

This ensures dates are correctly interpreted regardless of how far in the past they are, fixing timestamp issues in LIST command responses.

Are there changes in behavior for the user?

No.

Related issue number

Fixes #196

Checklist

  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes

@sakosha
Copy link
Contributor

sakosha commented Sep 23, 2025

Could you add a test for this? I haven't noticed the bug for my server

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

Successfully merging this pull request may close these issues.

Client list using "LIST" parses dates more than 6 months in the past without a year as the next year

2 participants