🐞 Critical Bug — Variable Name Error in Date Validation (`DeeringAutoDownloadCode.py`)

[orbaps]

Summary

A critical variable naming bug exists in the validate_and_compare_dates() function of DeeringAutoDownloadCode.py.
The function defines parameters start_date and end_date, but references undefined variables start_date_input and end_date_input, causing a NameError and breaking the core download workflow.

def validate_and_compare_dates(start_date, end_date):
    # Parameters are start_date, end_date but code uses:
    start_date = datetime.strptime(start_date_input, '%Y-%m-%d')  # ❌ Undefined variable
    end_date = datetime.strptime(end_date_input, '%Y-%m-%d')      # ❌ Undefined variable

[KeshavThathera]

hey @orbaps i would like to work on this issue .i think i can contribute and this is a good first issue for me.

[Rahul-2k4]

Hi! @orbaps I’d like to work on this issue.
The error occurs because the function parameters start_date and end_date are being overridden by undefined variables (start_date_input and end_date_input).
I will prepare a fix to correctly use the function arguments and add a small validation check to prevent similar issues in the future. I’ll open a PR shortly.

[rahulcse129]

Hi @fwitmer,
I would like to contribute in this Issue & request PR.

[praveen-86176]

hey @orbaps I fixed a variable naming issue in validate_and_compare_dates() where the function parameters (start_date and end_date) were getting overwritten, which made the logic harder to follow and error-prone.
I cleaned this up by using separate variables (start_date_obj, end_date_obj) for the parsed datetime values, so the original inputs remain unchanged. I also removed some old commented code that referenced undefined variables.
On top of that, I added basic input type validation, improved the error messages to be more descriptive, and updated the docstring for better clarity.
I tested the function with valid dates, invalid formats, and cases where the start date comes after the end date — everything works as expected now.

[SamarthTechKing]

Hi @orbaps ,

I looked into an issue in validate_and_compare_dates() where the function parameters (start_date, end_date) were not being used correctly and the implementation referenced outdated/undefined variables. This could lead to runtime errors and break the date validation step in the download workflow.

Approach:
I reviewed how date inputs flow into the function and identified that the parameters were being overwritten and that older variable names were still referenced in the parsing logic. To address this, I refactored the function to clearly separate input values from parsed datetime objects by introducing start_date_obj and end_date_obj. This keeps the original inputs unchanged and makes the logic easier to read and maintain.

I also removed stale commented code that referenced undefined variables, added basic input validation, improved error messages for invalid formats and incorrect date ordering, and updated the docstring for better clarity.

I tested the function with valid inputs, invalid date formats, and cases where the start date is later than the end date, and the behavior is now consistent and robust across all scenarios.

I’d be happy to contribute this fix and take up the issue if you think it would be useful.

[IbrahimHassan-arch]

Hi, I’d like to work on this issue. Is it still available?