Open jurjen74 opened 5 years ago
Yes we are fully aware of this, and if designed now we would've used the DateTimeOffset. However to get this into the framework we'll need to think of a good upgrade path for it.
We'll schedule this for future development and talk more in detail how we should address it.
Regards
Or rather, all dates should be stored in UTC
in the database and converted to local machine time when loaded.
you don't need to use DateTimeOffset, if you keep your backend dates in UTC. then the UI should do the translation to user's preference (time zone + style).
Yes we're looking into migrating to UTC in the database and adding a new property for it. The existing properties would be used to hold the values converted to the current time zone.
But that does not preserve the time zone info. The back-end is in UTC (because I'm in Azure). So converting it to a datetime is NOT the same.
Hi guys! This problem still exists and makes a lot of pain for newcomers when they first deploy MVC project with the sample data. I ran into this issue while deploying cms from my local machine to Azure and took about 2 hours to find the root cause of this issue.
This was never prioritized as the kind of applications Piranha tend to be used for is usually one time zone. The simplest solution is to simply configure the correct time zone for your web app.
Regards
Hi,
The published date is a DateTime value, without time zone info. I published a page on my dev machine, which turned out to be scheduled on production. Production was on Azure (UTC) and local dev time was in CET. With time zone stored in a DateTimeOffset field this can be avoided.
Cheers,
Jurjen