In the classic engine, $dateToString and $dateFromString were validated using the validate...Format functions in date_time_support.cpp, which were void functions that would uassert if an invalid format was detected.

When implementing $dateToString in SBE in SERVER-49979, we added isValid...Format functions which do not uassert, and instead return a boolean indicating whether the format is valid. We created a new vm builtin, builtinIsValidToStringFormat to call this function from the stage builder.

However, while implementing $dateFromString in SERVER-49978, we decided to add a builtin called validateFromStringFormat instead, which calls TimeZone::validateFromStringFormat, allows it to uassert, and returns true otherwise. Since it had recently been decided that it was alright for SBE VM functions to uassert, we determined it was more important to have detailed errors than a validation function that returns a true/false value.

This ticket should, at a minimum, involve updating dateToString format validation to function in the same way, where detailed errors can be surfaced from uasserts within date_time_support.

We should also consider either deleting the new isValid...Format functions inside the date_time_support library, or modifying them so that they can run the validation function, uassert, but still return a true/false value, so the SBE builtins can simply return TimeZone::isValid...StringFormat.

It's possible the function where the actual validation happens, which was made into a templated function during SERVER-49978 to allow the option to suppress errors, can go back to a simple function without a template that always uasserts on an invalid format.