A bug has been identified which on the 23.0-release sysdate
returns UTC time instead of local time when evaluated in a PSQL-scope.
However, that bug didn’t cause your question.
In this case, the question is triggered due to the way dates are displayed in the Query Tool. All dates are displayed in UTC-time.
For example, when executing:
select sysdateutc
, to_char(sysdateutc, 'YYYYMMDDHH24MISS') sysdateutctxt
, sysdate
, to_char(sysdate, 'YYYYMMDDHH24MISS') sysdatetxt
the results will be:

Which displays that the actual date value is in local timezone (as visible in column sysdatetxt
), but the displayed value is in UTC.
A similar question can arise when calculating the time difference between local time and UTC-time as in:
select sysdateutc - sysdate
The outcome is 0, since both refer to the same time. This can feel counterintuitive at first. Although the wall clock large hand points to another hour in UTC and CET, the actual time is identical.
In general it is recommended to only work with UTC times when applications may bridge timezones or timezone settings.
In case it is necessary to process the difference in seconds between local and UTC time, please use utcoffset
as in:
select utcoffset
For CET, the outcome will be 3600 currently. In DST that would be 7200.
Please note that there are locations on the world with fractional hour offsets compared to UTC.
A somewhat hacky approach could be to add the needed offset to the UTC time as in:
select sysdateutc + utcoffset / 86400
However, note that the resulting date/time is internally still a UTC time, which happens to match some other local time. One of the most frequently found issues in setting up time in the past was that someone changed fiddled with the timezone and clock to get a value matching the wallclock. However, often the system clock was off by for instance one hour and the timezone in the other direction. So when using this hack, please make sure to clearly reflect the meaning of the date/time in variable and colum naming.