Skip to content

Future Date Validation#841

Merged
Akol125 merged 7 commits intomasterfrom
VED-307-Future-Dates
Sep 24, 2025
Merged

Future Date Validation#841
Akol125 merged 7 commits intomasterfrom
VED-307-Future-Dates

Conversation

@Akol125
Copy link
Copy Markdown
Contributor

@Akol125 Akol125 commented Sep 23, 2025

Summary

  • Routine Change
  • ❗ Breaking Change
  • 🤖 Operational or Infrastructure Change
  • ✨ New Feature
  • ⚠️ Potential issues that might be caused by this change

Add any other relevant notes or explanations here. Remove this line if you have nothing to add.

Reviews Required

  • Dev
  • Test
  • Tech Author
  • Product Owner

Review Checklist

ℹ️ This section is to be filled in by the reviewer.

  • I have reviewed the changes in this PR and they fill all or part of the acceptance criteria of the ticket, and the code is in a mergeable state.
  • If there were infrastructure, operational, or build changes, I have made sure there is sufficient evidence that the changes will work.
  • I have ensured the changelog has been updated by the submitter, if necessary.

@github-actions
Copy link
Copy Markdown
Contributor

This branch is working on a ticket in the NHS England VED JIRA Project. Here's a handy link to the ticket:

VED-307

"2000-02-30", # Invalid combination of month and day
]

for_future_dates = [
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not essential, but the future-proof way of doing this would be to generate date strings with strptime() based on offsets from the time now. That would mean we can have reliable test cases for dates which were only months or days in the future as well

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry, only managed to get to review this now due to some internal calls.

This is absolutely mandatory. Even if we are deferring until the year 3000, you never write unit tests that are going to fail at some point and need bumping.

Typically, I would advocate mocking datetime.now(), but the validation tests are such spaghetti, that James' suggestion to use time offsets so we can guarantee it is always a future date would be sufficient.

JamesW1-NHS
JamesW1-NHS previously approved these changes Sep 24, 2025
@sonarqubecloud
Copy link
Copy Markdown

@Akol125 Akol125 enabled auto-merge (squash) September 24, 2025 12:10
@Akol125 Akol125 merged commit 202f0a3 into master Sep 24, 2025
7 checks passed
@Akol125 Akol125 deleted the VED-307-Future-Dates branch September 24, 2025 12:12
now = datetime.now(parsed_value.tzinfo) if parsed_value.tzinfo else datetime.now()
elif isinstance(parsed_value, date):
now = datetime.now().date()
if parsed_value > now:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code will crash if parsed_value is not a datetime or date and now will not be assigned a value. I have checked and your code is always called in a safe way - i.e. it is only ever provided a datetime or date.

However, it might be worth stipulating this can only be called by functions which guarantee the input is date | datetime. Or handling the case where it isn't. Probably the first option is simplest and okay.

now = datetime.now().date()
if parsed_value > now:
return True
return False No newline at end of file
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, but could use a newline.

Akol125 pushed a commit that referenced this pull request Nov 7, 2025
* Datetime must not be in the future
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.

4 participants