This is not possible to my knowledge.
I also think it is counterproductive.
Think of your marketing cloud instance like an "onion" with several layers.
There is a central "processing core", and around it you build more "processing layers" of tables, scripts, queries etc, as well as one or several outward facing "display layers" (e.g. an email, an export file,...)
At the very core are the data views - tables marketing cloud simply has by default and that you'll need to work with.
All dates in the marketing cloud uses in the core are system time (UTC-6)
(except for BusinessUnitUnsubscribes, where it explicitly says "UnsubDateUTC")
Around the core, you build a set of data extensions, queries, whatever. Definitely consider Data Extensions that catch & store data your inner "processing layer".
You might very often need the data in here to make date comparisons, calculations etc. with the data stored in the "core". Random example: Compare your stored time with a click date in the data view. Therefore: Leave all your timestamps in the "processing layer" in system time, i.e. consistent with the central infrastructure.
a) you will needlessly complicate all comparison / calculation operations that involves "core" data.
b) you will complicate the act of storing data: in each email send log you build, each SQL you create that should store a timestamp, you'll have to think of transformation, instead of just using the default functions like NOW() or GetDate().
c) Worst case, people operating the system will not even know of the disparity and interpret data wrongly or build inconsistent processes.
d) What if several display processes need different formats, e.g. your next export goes to a system that can only handle UTC? Then all this transformation was for nothing, and you have to revert it back for a specific process again.
Once you need the data exposed somehow - consider this your "display layer" -
This could be display in an email, on a webpage, exports to other systems, API calls to other systems etc., THEN think about formatting to the desired timeformat using SQL or AMPScript / SSJS to restructure "raw dates" into a desired format like UTC, or UTC-3, or UTC-7 / 8 considering daylight savings,...
This is also the first time you have to think about formats like "date with or without time, US or French date format etc." Before that, just use the system standard.
Plus, as a good practice, NAME your date fields explicitly to make clear to every user what he is dealing with.
e.g. call a field in the processing layer "timestampSystemTime" or timestampUTC-6.
In your Data Extensions in the display layer (e.g. an export DE) call the timestamps something like "localTime" (if this is clear from your base of operations) or timestampUTC etc.
Hope this made some sense :)