Handling @db.Date fields client side from different Timezones (Postgres)
We have a database where some tables have date only fields (
When the server sends this data then javscript will create a
This causes the
We COULD simply say that all dates that we receive client side we add the current timezones offset so that it will then be correctly parsed as
So in short we do need some way to differenciate between how we parse
If we have the service for that entity client and server side then we could add a manual mapping client side to only parse the specific fields that we know are
I also don't want to resort to saving them as DateStrings since the Database shouldn't have to adjust (and lower) its capabilities because of the client and we would loose some possibilities that Dates can do which strings can't.
DateTime @db.Date) while others are regular DateTime fields.When the server sends this data then javscript will create a
new Date() for both since we don't have a date only primitive there.This causes the
@db.Date field which is stored as 2025-04-20 to be understood as a UTC 00:00 date. Therefore if I'm in New York which is -4h the date will result in 2020-04-19T20.00.000Z and the data will shift by one day in something like a calendar.We COULD simply say that all dates that we receive client side we add the current timezones offset so that it will then be correctly parsed as
2020-04-20T00.00.000Z. Then we woulc correctly have the beginning of the DB's date in the local timezone to correctly sort in the entry, BUT then we would mess up regular DateTime dates. A "createdAT" timestamp from 14:00 local NY time will come back to the same client with a 18:00 time which is WRONG.So in short we do need some way to differenciate between how we parse
DateTime and db.Date Dates. If we have the service for that entity client and server side then we could add a manual mapping client side to only parse the specific fields that we know are
db.Date fields. But this is not a generic or maintainance low solution.I also don't want to resort to saving them as DateStrings since the Database shouldn't have to adjust (and lower) its capabilities because of the client and we would loose some possibilities that Dates can do which strings can't.