A blog post written by a Neon user as part of Neon's Community series, sharing how they fixed a timezone issue when building a paking app.

Neon

Navigating timezone issues in JavaScript can be tricky. In a recent project, timezone metadata caused conflicts when booking parking slots. By removing timezone metadata and storing plain date-time strings, the team ensured consistent date and time storage across different timezones. Additionally, Neon’s easy connectivity and scalability proved beneficial for the project.

Fixing JavaScript Timezone Issues

The problem: Timezone conversions adding unwanted metadata

Imho this is horrible approach. In fact looks like you store now in db your local time point saved as US time. Which in fact is completely not accurate. User in Italy Rome will save i.e. his 12:00 AM while at the same time anyone in India Bangalore will save his own 16:30 PM. The reality in db will be that both will be stored as US time, and in fact even users were saving exactly in the same point of time, db will save it as 4,5h shift (even worse - both dates will not reflect real dates because of shift between local and us time…).
The better solution would be to convert local time to UTC then save in DB.

Just use UTC to store dates in your database.

Why the workaround? Simply use UTC for the database and local DateTime for the user.

In PostgreSQL, a “timestamp without time zone” (or simply “timestamp”) stores a date and time value without any time zone information. Also explore moment-timezone

whoever suggest storing datetime as string in database, please get away from keyboard.