Moving your SAP system to UTC

'Tis the the season for shutting down your SAP systems.... Again. And you likely did it last year aswell. Because SAP says you should, as the SAP system does not support the double timestamps that might occur.

Well, then you have the option of using "extended time". And some people might be very happy about this.
But what really happens, is that you get the wrong timestamp on items, up to half an hour off, and some businesses might not be happy with that.

Fortunately it's fairly simple to migrate to UTC (or UTC+1, or any other non-DST timezone) in your SAP system, even if you even missed it again this year, because the good news is: You have an entire Year to implement your changes. This will become an issue again next year.
The problem is that SAP apparently aren't able to provide a guide for how to do this, so many companies choose to have the added cost of shutting down the systems. But you really dont have to, changing to UTC time is really simple.
And all you have to do is:

Set servertime to UTC (or any non-DST timezone equivalent), on ALL servers in the instance

Set timezone on each client using transaction STZAC (while users are not active) identical to servertime

Set timezone for each user in transaction SU01 (or using a masschange or similar)

Download zip file from note 198411 and apply to SAP system using report TZCUSTIM

Verify timezone data consistency with report TZONECHECK, correct any problems as they show up.

Be aware that changing to UTC may also require downtime. This is required if you are moving your system back in time (eg from UTC+4 or equivalent to UTC+2 or equivalent), but not if you move it forward in time.

Benefits:

No need for downtime during start of DST

No need for NTP service during end of DST

Less confusion about time across multiple timezones

Easier to implement the use of various timeservices, NTP etc.

No time differences in documents of the type seen using SAPs “extended time”

Drawbacks:

Users may need time to adjust, as timestamps may vary between user- and servertime depending on programming, eg. Posting time is usually based on servertime, so end/beginning of time period may move a few hours.
Batchjobs are based on servertime, and jobs required to run at specific times may thus need to be rescheduled

Timezones must be set identical for ALL application servers, database servers, listeners etc for an entire system.

           Need to maintain time zones on a regular basis (they change a lot), see note 198411