The tests for createAppointment calculate the target time as follows:
test('creates appointment 124 in the future', () => {
const currentTime = Date.now();
const expectedTime = currentTime + 10713600 * 1000;
expect(createAppointment(124, currentTime)).toEqual(new Date(expectedTime));
});
This does not properly take into account shifts introduced by the beginning or end of Daylight Savings Time. The following solution from a student I mentored fails:
export function createAppointmentUTCDate(days, now = Date.now()) {
const appointment = new Date(now);
appointment.setDate(appointment.getDate() + days);
return appointment;
}
That should work - it’s perfectly acceptable solution to the stated task. What’s worse, that code would have worked if they had filed it at a different time - namely if they had worked on this exercise not within 124 days of DST beginning or ending. Obviously, passing or failing tests should not depend on the time of year that exercises are worked on.
For the same reason, the suggested solution is wrong:
export function createAppointment(days, now = Date.now()) {
return new Date(now + days * 24 * 3600 * 1000);
}
With the suggested solution, someone making an appointment for “at this time a week from now” may actually end up with an appointment an hour earlier or later, depending on their current date. I.e. at the time of this filing (25 July):
new Date(Date.now()) // Fri Jul 25 2025 15:13:49 GMT+0200
new Date(Date.now() + 10713600 * 1000) // Wed Nov 26 2025 14:13:35 GMT+0100 <--- suddenly one hour earlier according to local time
These tests and the recommended implementation should be corrected. If that is not possible without invalidating existing solutions, at the very least, the exercise instructions should state that this is the intended behavior, as it is wildly unintuitive for an appointments API.
