My understanding is:

From CMS 10, values are stored in the database are stored as UTC

The cmdlet converts all datetimes based on the server timezone where it is executed. I.e. if the server was set in Central European Time, the dates would be adjusted by an hour in the datebase or two hours if the date fell within a daylight saving adjustment (ie between April and October in the UK).

• A date originally stored as 1/5/2017 00:00 would become 30/4/2017 22:00 in the database (as daylight saving is applied in April / May) so CET (DST) = UTC + 2 hours 
• A date originally stored as 1/12/2017 00:00 would become 30/11/2017 23:00 in the database  CET = UTC + 1 hour 

What I've also noticed is that when viewing dates through the Episerver interface, they are adjusted to the local time (based on the user's local time passed via browser header), so you don't see the value stored in the database, you see the value stored in the database adjusted to your browsers local timezone (calculated at the exact date). This way all editors regardless of timezone will see the same moment.

This has confused me as some dates are an hour different than I expected, but this is because the conversion to local from UTC respects daylight savings, so there is an extra hour.

The Episerver API also converts dates to local time (based only on the server timezone) rather than the browser headers. You need to be aware of this when comparing datetimes especially with dates from external systems. When moving to DXC we had an issue where the data we migrated over (Episerver 10) was stored as UTC, but the old hosting environment was set up as GMT, where as the Azure DXC environment was UTC. This meant the conversions to Local time were different on the environment and the date comparison which previously worked were sometimes out by an hour (during Daylight savings).