Yes, current time value is correct, LastReqTime is off. Server OS is Windows Server 2008 R2 and OS clock is showing the correct time.

DB that is off by 15 min is up since 2021-11-23, the one that is off by 8 min is up since 2022-01-19 (select property('StartTime')). Computers, running those DBs, have respective uptimes of 120 and 60 days (according to task manager).

Is the db server running in a virtualized environment?

FWIW, a similar issue has already been discussed with v12, see this (unanswered) question.

I could imagine that this problem might arise on our servers once again after DST has been applied and before they have been rebooted then...

see attached picture in the question

It may just be me, but I just see a broken link in the question, not a picture.

So it sounds like the database engine has been running for the same amount of time that the computer has been up and running.

I wonder if the issue is related to the time on the computer changing while the database engine is running? Are you able to run a test where you stop and start the database engine (no need to reboot the computer) to see if the problem resolves?

Thanks, Reg

Restarting the DB service did resolve the issue, however it would be great if it would not repeat itself :)

Yes, DB server is running in a virtualized environment.

Shouldn't DST change push clock by an hour, not by some arbitrary amount?

Restarting the DB service did resolve the issue, however it would be great if it would not repeat itself :)

I surely agree that the time sources for the current server time and for "request time" should stay consistent over time (pun intended), and of course even across a DST change. (Though for expected ever-increasing and non-unique values like a DEFAULT TIMESTAMP, a DST change to the previous hour is of course difficult to achieve...)

But according to that older question, the impression remains that both kind of times do have different time sources that can fall apart.

And now I hope SQL Anywhere engineers will clarify this issue. :)

I recall Docker VMs having an issue where the clock would drift that would affect applications like SQLA that queried the system time. What virtualization environment are you running?

But even if the system time within a VM would loose precision over time compared to the host's system clock, that does not explain why SQL Anywhere would display different values for the current time and a "LastReqTime" of a currently started request, as in the OP's sample...

Environment is managed by our client, so I am not sure, but I doubt Docker is involved. According to msinfo32 system manufacturer is VMware, Inc, and after some Google I found a lot of info on VMware time drifting, including a huge document by VMware themselves https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf. Still, as already said by Volker Barth, SA should not count time differently.

Any advice on best way to contact SA engineers?

JBSchueler said this in an earlier comment... "The current time value should be the actual OS local time of day. The LastReqTime is based on an internal server clock."

Well, they do already read and discuss here, namely Jack Schueler, Chris Keating and Reg Domaratzki... :)

I have run a test that invokes the sa_performance_diagnostics() query cited at the start of the thread 500K times and cannot reproduce the behavior. And I often recommend using that procedure in an event to collect info to troubleshoot performance issues. To date, I have never seen a case where the values have drifted as shown here. You perhaps can open a support case and/or provide to this thread info about the virtualized environment (i.e., Hyper-V, VMWare), the virtualized OS and host (what OS is hosting the VM),has the VM ever been suspended and then reactivated - providing as much detail may help to recreate an environment that encounters the behavior.