-
Notifications
You must be signed in to change notification settings - Fork 751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ok with this
} | ||
} | ||
|
||
public TimeZoneInfo TimeZone { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into the failing test and my suggested change (without the typo) was what we needed to get that test to pass again. This should be green now and ready to merge.
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.