PostgreSqlFetchedJob npgsql DateTimeOffset change for timestamptz column

[fahrigoktuna]

Regarding #384 PR - if it doest not sound good . With the help of this PR you may change DateTime type to DateTimeOffSet in PostgreSqlFetchedJob according to Npgsql Mapping Table => https://www.npgsql.org/doc/types/basic.html. So that, there will be no problem deleting jobs from jobqueue table.

[azygis]

There are no timestamptz columns since 1.9.10 which was released almost 2 years ago.

What are the problems that you speak of? Neither PR makes sense as they are right now - this one now has a different CLR type from what's expected by Npgsql (should be timestamp -> DateTime), the other PR removes a safeguard which ensures only the exact same job is deleted.

[fahrigoktuna]

Latest code branch master, 1.20.10 package. Please look at Install v19.sql.

I think you had done convertion timestamp to timestamptz columns with tag 1.9.10

[azygis]

Sorry, you're right! This whole debacle with timestamp changes with Npgsql is a blur at this point. But still, the datetime should be what it is. What's the problem with current implementation? I only see what the potential fixes are, but not what the problem is. Do the dates mismatch? Or?

[fahrigoktuna]

Problem is that after job executed and marked as Succeeded. I expect that it should be removed from jobqueue table(hard delete). However, they are still remaining in jobqueue table. I debug it and change DateTime to DateTimeOffSet delete operation works. Maybe you should try, i dont event figure out that no one is noticed
https://www.npgsql.org/doc/types/datetime.html

Note: Datetime Kind is Local which is +03:00 for me.

[fahrigoktuna]

Have you had a chance to look at it?

[azygis]

No, not during holiday season.

[azygis]

I fixed the build so the tests could run. Unfortunately, one of them fails, and that one does relate to the change.

[azygis]

I had a look at the mapping table and timestamptz should indeed translate to either DateTime at UTC, or DateTimeOffset with offset of the server. I think the fix in this request does not really fix anything by changing the type.

Can you provide a minimal reproducible example? All environments and applications on my end work correctly, I have no zombie rows in the table.

Are you using the appcontext switch to bring back the legacy behavior? I personally never used it and not really sure if it can mess these queries. Based on

Note: Datetime Kind is Local which is +03:00 for me.

it feels like you may be using the switch. Please confirm that.