UTC timestamp value issue with SQL anywhere 17

[former_SQLA_member1694879]

we have declared the below column with table 1.

last_chg_utc datetime null default utc timestamp,

while inserting the row against table 1, default value is automatically populated for last_chg_utc column

The problem is default value is inserting with adding future date for every insert. For ex: today date is 08-11-2023 , default value is setting as 09-11-2023 for every insert it is incrementing the date value

Note: we are not setting any value against (last_chg_utc column) by default it is settting the value

kindly let us know why it is inserting the future date value by default.

how to resolve this automatic date increment issue

[former_SQLA_member1694879]

What is the date on the host server?

[former_SQLA_member1694919]

host server date is EST time today date

[former_SQLA_member1694879]

If it's a Windows server run this in Powershell - it should output the date in UTC as you want it in SQL Anywhere - if it's not, then you need to look at the host server as your problem.

Get-Date -date (Get-Date).ToUniversalTime()-uformat %y%m%d%H%M%j

[VolkerBarth]

How do you "check" the timestamp values, i.e. with what query, and what is exactly displayed?

I'm asking as the display of dates and timestamps is affected by settings for options like date_format or timestamp_with_time_zone_format, and with SQL Anywehre 17, you can also let the database server "run in a different time zone".

What does this query reveal in DBISQL?

select connection_property('timestamp_with_time_zone_format'),
   connection_property('time_zone'), -- are TZs simulated?
   connection_property('time_zone_adjustment'),
   current timestamp,
   cast(current timestamp as timestamp with time zone),
   current utc timestamp

Here's my German-based result (i.e. CET, UTC+1):

YYYY-MM-DD HH:NN:SS.SSS+HH:NN;
;
60;
2023-11-08 13:23:58.241;
2023-11-08 13:23:58.241+01:00;
2023-11-08 12:23:58.241+00:00

Note, the 5th column (current timestamp displayed with time zone) returns a different time than the 6th (current utc timestamp) because it isn't normalized to UTC0.

[VolkerBarth]

FWIW, in the past, there have been some pitfalls with DEFAULT TIMESTAMP columns when the system clock was re-synchronized "back" according to changes due to DST or mere "inaccurate clocks" issues while the database server was running - as the DEFAULT IMESTAMP values seem to only increase monotonically while the database server is running and are prevented to "go back".

I don't know if those issues also applied to DEFAULT UTC TIMESTAMP and apply to your problem - but you might have a look here...