SQL Server 2008 onward - Globalization with Date Time
With stand-alone systems which will never be merged using the local system clock's time has appeal. There is no need for conversion going into nor coming from the database. What you see is what you get. No matter how you access the DB, whether application, reports or ad hoc query the results need no post-processing.

However .. some places observer daylight saving. This means that once (?) a year there will be an hour-long gap in the data. And once (?) a year there will be an hour-long time reversal where, say, sorting on identity column and sorting on a datetime column will produce different ordering.

Now, we don't know your application. We don't know how important any of this could be, or what other work-arounds you might think up, or whether a crazy hour here or there is a problem or not, or any of the other factors that might come into play. But if it is then UTC or time offset is the way to go.