Make sure TimeZone doesn't store to database just by setting the prop #3037
Conversation
|
This fails the LoadPortalSettings_Sets_TimeZone_Property_To_Local_TimeZone test. I have no idea how to adjust this test so it will pass. We'll need to discuss. |
| } | ||
| } | ||
|
|
||
| public TimeZoneInfo TimeZone { get; set; } |
There was a problem hiding this comment.
Should we continue defaulting this to TimeZoneInfo.Local?
| public TimeZoneInfo TimeZone { get; set; } | |
| public TimeZoneInfo TimeZone { get; set; } = TuneZoneInfo.Local; |
There was a problem hiding this comment.
Watch out, you have TuneZone instead of TimeZone in your suggested change here...
|
After thinking about this again, is this just a code cleanup effort or is it causing a bug? If this is just cleanup, I think I would prefer targetting this for 10 release just to make sure we don't break something along the way. Everything that touches times scares me :) |
From my point of view it's code cleanup |
|
@donker can you look at the conflict and the failing test... |
Currently when setting the TimeZone property on the PortalSettings object it will persist to the database and clears the cache. This is obviously not a good idea. The front end already sets the TimeZone when an admin changes the value in the site settings personabar module.