It looks like @mattbroussard did correctly diagnose a similar issue in the USDR GOST project.
What's happening is that when reading dates out of a date column in Postgres, knex passes the raw date string to a JS date constructor (e.g. new Date('2022-09-30')). This resolves the date to an exact time (midnight on that date in the server's timezone). Then, when we serialize that date as JSON to send over the network, the time and timezone information are preserved.
Since the server's timezone and the user's timezone don't always agree, the date can end up +/- one day from when it was intended to be.
Rather than try to accommodate for server's timezone somewhere, we can prevent the addition of time information to Postgres dates by overriding the knex date parser.
Fixes #381
It looks like @mattbroussard did correctly diagnose a similar issue in the USDR GOST project.
What's happening is that when reading dates out of a date column in Postgres, knex passes the raw date string to a JS date constructor (e.g.
new Date('2022-09-30')). This resolves the date to an exact time (midnight on that date in the server's timezone). Then, when we serialize that date as JSON to send over the network, the time and timezone information are preserved.Since the server's timezone and the user's timezone don't always agree, the date can end up +/- one day from when it was intended to be.
Rather than try to accommodate for server's timezone somewhere, we can prevent the addition of time information to Postgres dates by overriding the knex date parser.
BEFORE
AFTER