Steps to reproduce

1. Set up Nextcloud 33 with Tables 2.0.1
2. User timezone: Europe/Zurich (CEST, UTC+2 in summer / CET, UTC+1 in winter)
3. Server timezone: Europe/Zurich, PHP: Europe/Zurich, DB: SYSTEM (= Europe/Zurich)
4. Create a table with a datetime column
5. Enter a time (e.g. 8:00) and save
6. Open the row for editing again (modal or inline)

Expected behavior

The saved time (8:00) is shown correctly in the edit form.

Actual behavior

Every time you open the edit form and save, the time is shifted by the
current UTC offset:

• In summer (CEST, UTC+2): shifts by -2h each save
• In winter (CET, UTC+1): shifts by -1h each save

This means the shift is DST-aware — it uses the local timezone offset
of the date being edited, not a fixed offset. Dates created before
the March DST switch shift by -1h, dates after shift by -2h.

Tables app version

2.0.1

Browser

Firefox 149, Chrome 146

Client operating system

Windows

Operating system

Ubuntu 24.04.4 LTS (up to date)

Web server

Apache

PHP engine version

PHP 8.3

Database

MariaDB

Additional info

The bug does NOT occur on:

• Nextcloud 32.0.6 with Tables 1.0.5 (same user timezone, same server config)

This suggests a regression introduced in Tables 2.0.x, likely related to
the new inline datetime editing feature introduced in this version.

The time is shifted correctly for display (DST-aware), but the edit form
appears to interpret the stored naive datetime string as local time and
converts it to UTC on save — effectively subtracting the UTC offset each
time the row is saved.