I knew that new Date('YYYY-MM-DD') sets the time to
midnight. What I didn’t know was that it sets it to
midnight in UTC.
This is all the Date constructor could do in this use-case. There is no timezone specified and assuming one other than UTC could easily result in undefined behavior.
I think a better "lesson learned" in this case is to remove all ambiguity from datetime types by internally using only UTC representations for calculations and reserve timezone usage for display purposes.
There is no ambiguity. The Date constructor provides a timezone offset:
myDate.getTimezonOffset();
It outputs the number of minutes different from UTC time. I use this to display server time in both server local and zulu (UTC) via a WebSocket broadcast every 950ms.
>> I think a better "lesson learned" in this case is to remove all ambiguity from datetime types ...
> There is no ambiguity.
The ambiguity I referenced was regarding program logic, not how `Date` operates when given only the year/month/date part of an instant. Perhaps I should have said instead:
I think a better "lesson learned" in this case is to
remove all ambiguity when using datetime types
by internally using only UTC representations for
calculations ...
I've only just realised people mean UTC0 when they say store/use dates in UTC. For some reason, I've always thought it meant storing it in the ISO format. YYYY-MM-DD HH:mm:ss.sssZ which I've always done.
I think a better "lesson learned" in this case is to remove all ambiguity from datetime types by internally using only UTC representations for calculations and reserve timezone usage for display purposes.