And that may be completely wrong... since the UI would appear to be three separate boxes,allowing data entry.
Now, we begin entering, (say the order is day, month, year). I begin with entering 3 and then tab to the next field. Validation is done. The original code validates 3 as date, and everything is ok. Your code attempts validating "3" as a date, and fails.
So, the form logic would need changing to only validate upon leaving the triplet (which is nasty, and would be more WTF worthy) OR the application would need changing to have a date entry field // which would be better. BUT, there may be some business case for entering the date as number tab number tab number tab.
Offhand, I don't know what it is, though. But, if it exists, I can see that:
1 - I don't know if VB supports edit fields. In any case, I don't the syntax, and for quick turn around and easy maintainance I may recommend doing edit validation this way.
2 - The design allows for "heads down" entry.
3 - It is easy to find and modify the edit routine for the field. For maintainance, I would probably merge the three edit routines into one as well.
4 - The wierd feature is that the field length is defined in the edit routine, but is not referenced. I was expecting a Len(sString) somewhere. But it doesn't matter. EI. 0003 is still 3, and a valid day.
5 - Based on the code snippet presented, your postulated replacement would qualify as a WTF; deploying would entail redesign.