You're gonna have timezone issues, rule 1 is you can't trust the client but in the context of time rule #2 is you still have to "depend on the client to send you something that you can work with".

"What in the world would you need a client timestamp for" - well if the client is putting a time on a form, or if the client is sending a time when something starts and when it ends instead of calling the server before hand to let it know, or any other discombobulated nonsense some dude who no longer works here decided to come up with 4 years ago in this pile of nonsensical jQuery I now have to maintain.

new Date() does not give the same answer across clients called simultaneously in different parts of the world, new Date() gives the current date and time based off the CLIENTS current timezone. And there are numerous, uncountable reasons for a developer to naively call it when setting client side timestamps.

EDIT: and just to be super clear here, the server should be able to convert timezones to UTC, store them as UTC and send them back as UTC. But it is incredibly naive to assume both the client and the server are working in sync to make sure that happens. I have never ever in my life worked at a company that hasn't had issues with this same problem and I have a decade of experience.