Booking up for Beauty: invalid date/time output?

In the Booking up for Beauty exercise, one task involves implementing the description function to return a string version of an appointment date.

In my solution, I’ve first tried to interpolate appointmentDate in the output string (see iteration 1). That failed with a strange subtle difference in output:

Expected: Equals "You have an appointment on 3/29/2019 3:00:00 PM."
Actual:   "You have an appointment on 3/29/2019 3:00:00PM."

I then tried to use appointmentDate.ToString("G") (see iteration 3), but that failed with the same message.

Finally, I specified a custom format string directly (appointmentDate.ToString("M/d/yyyy h:mm:ss tt") - see iteration 4) and the tests passed.

What’s weird is that locally, all of those iterations pass all tests. Furthermore, the output difference is very subtle. I also noticed that lots of community solutions are marked as failed (see for example this one), although I don’t know if it’s because of this.

Is it possible that the test runner does not output the exact same date/time format when using the default format in the test runner?

That’s weird, as the tests all use a fixed culture: [<UseCulture(“en-US”)>] I wonder if this is due to the Docker image missing something.

I think we’ve hit a similar issue as this one: DateTime.ToString() on alpine-3.17 are broken · Issue #80551 · dotnet/runtime · GitHub

I think the best way to fix this would be to change the tests to use DateTime.ToString() also when checking the expected output. This way, if the output differs between platforms (as it is currently), the tests would pass everywhere.

The only issue I see is that if someone (e.g. me :wink:) hard-coded the date format in their submission, it might fail the tests if we apply the above fix.

Damn, this is all quite annoying! The idea of the exercise is partly to have students experience that when one doesn’t specify a format string, that the output will automatically be in the culture’s output format.

This issue really baffled me - I thought it was an issue with my code and my not correctly specifying the output format. I worked around it by replacing “AM” with " AM" and “PM” with " PM": crude but in this case, effective!