When looking through online forums at date related questions a typical advice is like this:

Store dates in UTC and convert to a local timezone on display.

For many cases this is the absolute right choice. So if this is a date when an article was published it's useful for users to get their local time.

However we all know it - there never is a single true answer and the correct answer always is "it depends." An example:

You are building a system for booking a concert hall. Such tickets can be a bit in the future and have a printed time. Also there are other processes depending on that time (catering staff and security have to be in time etc.)

When storing this date in UTC all will be fineat first, browsing through the calendar will look fine and if somebody comes from across the timezone border they can see their local time. Nice.

Now politics come into play and change the rules for daylight saving times. Suddenly your event is one hour off. Sad.

And yes, these things happen. For instance:

• The EU is debating to get rid of daylight saving time in future. (as it was intended by the previous commission and the current hasn't touched it yet that's probably not going to happen,  but you never know)
• Russia in 2011 decided to stay on DST and not switch back, but in 2014, after protests, they decided to switch to permanent "normal" time.
• Samoa introduced DST only in 2010, while they planned to do that in 2009 but delayed due to Tsunami
• Crimea switched timezone, when Russia took control
• One can dream of the world at least unifying the DST switchover dates some time in future

Thus, if the local time is important the advice to store UTC might not be so good, but rather store date, time and timezone. Best form for storing the timezone is not in the common abbreviation like "CEST" or "ET" which can be ambiguous (AST could be Arabian Standard Time UTC+3h or Atlantic Standard Time UTC-4h) but in the form used by the IANA tz database as Europe/Berlin or America/New_York.