SqlServer: Error on Call to a member function setTimezone() on false …\app\Http\RequestHandlers\SiteLogsPage.php:77

[FrankWarius]

Call to a member function setTimezone() on false …\app\Http\RequestHandlers\SiteLogsPage.php:77
#0 …\app\Http\Middleware\RequestHandler.php(52): Fisharebest\Webtrees\Http\RequestHandlers\SiteLogsPage->handle(Object(Nyholm\Psr7\ServerRequest))

line 76:

   $earliest = DateTimeImmutable::createFromFormat('Y-m-d H:i:s', $earliest, new DateTimeZone('UTC'))
            ->setTimezone(new DateTimeZone(Auth::user()->getPreference(UserInterface::PREF_TIME_ZONE, 'UTC')))
            ->format('Y-m-d');

“Y-m-d H:i:s” is requested (MySQL standard, no milliseconds), but SqlSrv datetime (always) has 3 millisecond digits. Hence the error. Excerpt from log table

log_id log_time log_type log_message ip_address user_id gedcom_id
1 2025-10-28 14:32:42.853 config Site preference "WT_SCHEMA_VERSION" set to "1" 127.0.0.1 NULL NULL
2 2025-10-28 14:32:42.877 config Site preference "WT_SCHEMA_VERSION" set to "2" 127.0.0.1 NULL NULL

SqlSrv datetime is obsolete and should be replaced by datetime2(precision). So here datetime2(0).

webtrees uses in Migration0.php line 95 the default precision:

        DB::schema()->create('log', static function (Blueprint $table): void {
            $table->integer('log_id', true);
            $table->timestamp('log_time')->useCurrent();

that in vendor/iluminate/database/Shema/Grammars, it is implemented correctly for our purposes in MySql, but is implemented unfavorably for SqlSrv in SqlServerGrammer.php line 837:
return $column->precision ? “datetime2($column->precision)” : ‘datetime’;

Fix:
use in all DB definition the requested precision 0 like migraion0.php line 97
$table->timestamp('log_time', 0)->useCurrent();

I change 5 occurrence in mig0, 1 in mig40

and additionally a change in SqlServerGrammer.php line 837
return isset($column->precision) ? “datetime2($column->precision)” : ‘datetime’;
I'm not sure how to make this change permanent, as it gets overwritten with every composer update.

[fisharebest]

use in all DB definition the requested precision 0 like migraion0.php line 97

Will this help?

return $column->precision ? “datetime2($column->precision)” : ‘datetime’

It looks like 0 and null will give datetime (not datetime2(0))

[fisharebest]

and additionally a change in SqlServerGrammer.php line 837

Ah. I answered before I read all the comment ;-)

[fisharebest]

Perhaps we should add a precision (3? 6?) to all our defintions?

[FrankWarius]

Both work fine with SqlSrv, but I can't estimate the impact on MySql.

Migration is particularly difficult; my change log goes back to 2011 and is 133 MB in size (exported).

(The complete migration of data from MariaDB to SqlSrv took me 3 days and 3 C# programs).

[fisharebest]

I think SQLite does not use milliseconds.

I will need to create a function fromDatabaseTimestamp() that accepts timestamps with and without fractional seconds.

The time/timestamp handling is a bit messy. There is now the PSR-20 clock specification.

I will look at simplifying this code at the same time.

[FrankWarius]

I asked ChatGPT on an experimental basis, but I think you know better yourself :-)

1. Workaround for the Illuminate T-SQL Datetime bug
   in the relevant function migration*.php:

use Illuminate\Database\Migrations\Migration;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void
    {
        // Direkt als DATETIME2(0) mit Default anlegen
        DB::unprepared("
            ALTER TABLE [dbo].[Auftraege]
            ADD [zeit] DATETIME2(0) NOT NULL
                CONSTRAINT [DF_Auftraege_zeit] DEFAULT (SYSUTCDATETIME());
        ");
    }

    public function down(): void
    {
        // Default droppen, dann Spalte droppen (Reihenfolge!)
        DB::unprepared("
            ALTER TABLE [dbo].[Auftraege] DROP CONSTRAINT [DF_Auftraege_zeit];
            ALTER TABLE [dbo].[Auftraege] DROP COLUMN [zeit];
        ");
    }
};

2. Fundamental new timestamp action:
   Use DateTimeImmutable and Carbon\CarbonImmutable

[FrankWarius]

Another time zone issue with log and changelog (production environment is correct):

The local time of the server and client is CET (Europe/Berlin). The log timestamp is, for example, 2025-11-25 15:30:20 UTC, but should be CET. The CHAN part in the INDI record is correct. See: this changelog entry

[fisharebest]

The database columns are always stored in UTC. We convert to each user's local time when we display these values.

For example, if you change your timezone in your account settings, then the timestamps in the control panel will change.

The CHAN record does not have a timezone. It is just "text".

For imported data, the timezone is unknown.
For data created in webtrees, we should also use UTC - but we do not convert it.

The code sets the timezone date_default_timezone_set('UTC'); during startup. So, when we create the CHAN record ($today = strtoupper(date('d M Y'));, $now = date('H:i:s');), we should also get UTC.

You say you are seeing local time in the CHAN record. This is unexpected. Have you modified your site in any way?

[FrankWarius]

this happend right now local time 18:05 Europe/Berlin on a your Main branch (only modified .vscode)

[FrankWarius]

[FrankWarius]

... and of course I used the simple datetime2(0) for datetime workaround in illuminate SqlServerGrammer typeTimestamp:
return $column->precision ? “datetime2($column->precision)” : ‘datetime2(0)’;