The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong.
For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date.
When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.
Exactly: it isn't difficult to safely use Date() to hold and compare dates, but you need enough experience to avoid the gotchas (which are not unique to JavaScript).
Even just using dates can be a mess. At midday UTC everyone experiences the same date. The other 23 hours of the day, a varying proportion of people are experiencing a different date.
"using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dates.
It really comes down to "does your application need to worry about time zones?" If so, then you probably need to treat this seriously, and getting help with that is good. If not, not.
> At midday UTC everyone experiences the same date.
Afraid not. Kiribati, Tonga, Samoa, and New Zealand might be in the following day - they all experience UTC+13. Kiribati and Samoa even experience UTC+14.
Sure, but I was referring more to the times you actually do just want a date. It's perfect for a birthday, or "this day in history", or any number of other things. Nobody really cares that while it was Tuesday where you were born, it was Wednesday for them.
In some instances, if you really only care about the day something happened, adding a time is just extra details to screw up. But if you do need need a a time, you very well may also need a timezone.
This is why Javascript needs an equivalent to Java 8's LocalDate and LocalDateTime. It copied Java's terrible, fundamentally broken class for dealing with dates, if it could finally get around to copying the good date library that Java added later, that would be great.
For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date.
When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.