@maliming I've already tried doing just that, but it will not configure DateTime props to be mapped to timestampz (timestamp to timezone) in PGSQL, especially for framework modules (Identity...ecc) or any other modules integrated via ABP Suite..
I believe this to be an "infrastructural" issue.
When ABP is set to use PGSQL, it should configure the default handling of DateTimeKind (during read/write) , maybe something like this, but this code should be present upstream in ABP modules, it is not something configurable by end users of ABP; and event if it were, it would be really cumbersome and it should be clearly and extensively documented.
For example: all handling of I**AuditedEntity uses DateTime props (CreationTime, LastModificationTime, ecc), these should all be correctly mapped to timestampz (timestamp to timezone) and read / written with DateTimeKind.Utc....
this case is not directly related to ABP Framework. ABP Framework uses Entity Framework Core as the database provider. Do you get the same problem with a vanilla .NET console application?
I'll try to explain the issue once more....
With Npgsql < 6 mapping a DateTime prop to PGSQL's timestampz (timestamp with timezone) was cumbersome (or perhaps impossible).
With Npgsql 6+ , the default behavior has been changed (as I've linked above ), so DateTime is mapped to timestampz, but also requires explicit handling of DateTimeKind for the DateTime property, during read / write (I've also linked to this above). The Npgsql.EnableLegacyTimestampBehavior reverts Npgsql 6+'s behavior to that of previous versions, which means mapping DateTime props to timestamp (timestamp without timezone)
This does not allow read/write of temporal data with timezone information from/to PGSQL.
Having just started using ABP Commercial with version 5.0.1, I suspect that ABP <5 has never handled on PGSQL read/write of timezone-rich DateTime props (mapped to timestampz).
ABP Framework / Commercial, starting from 5.0.1 (I might be wrong on the precise version) has upgraded its Npgsql dependency to 6+. This has, obviously, caused issues due to the breaking change, and the above flag enables falling back to the previous behavior.
But a major issue remains: the fact that it is impossible to configure ABP framework modules (Identity...), as well as the default solution template, to map and then correctly read / write, DateTime properties with DateTimeKind = UTC to timestampz PGSQL columns. <<<< This is absolutely required for a Saas framework, as storing local DateTime is a major no-no with a geographically distributed user base.
This is a support question, is it going to be ignored?
Any feedback ?
I'm not sure if posting in this thread is "required" for issues with ABP 5+, but I'm requesting here also some feedback for this other support question related with the 5.1.2 version, question that hasn't received any feedback in 2 days...
I'm also encountering major PGSQL compatibility with DateTime entity props, now that Npgsql has been upgraded to 6+.
I've asked an "official" response to this issue on this support ticket.
I'm "escalating" to a support question this Github issue , because I need an official-as-possible response to the problem I'm facing.
It seems that with ABP Commercial based on ABP Framework 5+, when used with PostgreSQL DBMS with EFCore, there is no way to have DateTime entity properties mapped to DB columns of type timestamp with timezone and be correctly written / read by the ABP Framework infrastructure.
As far as I can tell, this issue has been introduced with the upgrade to Npgsql 6+, which has a breaking change with regards to the handling of .NET DateTime entity properties.
I require that DateTime columns be always mapped to timestamp with timezone and:
As I've commented elsewhere, Npgsql 6+ needs DateTime props to always have a DateTimeKind of UTC when written / read ( see this SO question and relevant answers ). If this is not supported, it entails that the ABP Framework with EFCore + Npgsql cannot correctly handle a multi-timezone application, which is a huge blocking issue for a "Saas framework".
What is the official stance on this issue?
