Fix timezone issue by using the Date() class instead of SQL NOW()

[yuvalt]

I'm in New York timezone, and that could be the reason why I see this issue. When the data is inserted to the database, it is in UTC. However due to the way the code is written, it will not actually dequeue until five hours later because of timezone issues in the code. My change fixes that (I verified). You should consider removing the timezone config option which way probably a way to try and resolve the issue... setting the timezone on the entire database is too intrusive, imho.

[mgcrea]

Hi, thanks for the PR!

The issue that I see is that having mismatched timezone does lead to other issues like having @default(now()) (which is the recommended prisma-way) to be incorrect since it uses the database time (unless I'm mistaken).

Agree that I don't really like the alignTimezone option which feels a bit hacky. But not really sure yet what is best. Did this option work for your use-case?

Will investigate a bit more,

[noxify]

Haven't tested it directly with prisma ( via @default), but could something like this solve the problem?

timezone('utc', now())

We're using this in our trigger logic while creating the audit records and previously we had the problem, that the timestamp ( via now() ) was in our local time zone and not utc.

[yuvalt]

Hi, thanks for the PR!

The issue that I see is that having mismatched timezone does lead to other issues like having @default(now()) (which is the recommended prisma-way) to be incorrect since it uses the database time (unless I'm mistaken).

Agree that I don't really like the alignTimezone option which feels a bit hacky. But not really sure yet what is best. Did this option work for your use-case?

Will investigate a bit more,

I tried to set the timezone option and it didn't work actually.

[yuvalt]

Hello @mgcrea -- did you get a chance to think about this?