What timezone does this plugin show?

[seanm]

When the plugin adds to mantis a 'related changeset' like this:

Is that time meant to be in local time? (Notice it does not display any time zone name).

I asked because, in that screenshot, the commit was actually done at 11:38 local time, yet mantis shows 07:38. A difference of exactly 4 hours, and I am in UTC - 4 currently.

I'm trying to figure out where this 4 hour delta comes from, but it would help to know what this is supposed to be showing. Is it meant to be local or UTC? Thanks.

[dregad]

what this is supposed to be showing. Is it meant to be local or UTC

All date and times displayed by Mantis should be local (based on timezone defined in user preferences).

Have a look at #317

[seanm]

So in fact we use both SourceSVN and SourceGitLab. The former is showing correct times (in local time zone); but the latter is showing incorrect time (4 hour shift). This is confirmed with multiple users (who all use the same local time anyway).

In the morning I will put some print statements, like around here seems useful? https://github.com/mantisbt-plugins/source-integration/blob/efeeba93e20ff1987edab6f4ccec89aa19ecf2f2/SourceGitlab/SourceGitlab.php#L426

[seanm]

OK, took a while since I'm not a PHP programmer. :)

If I log $p_json->created_at I get a string like 2025-10-29T15:59:48.000-04:00. i.e. it's getting local time from gitlab (if I understand this right). Is this expected?

In SourceChangeset's __construct, I see $t_timestamp = new DateTimeImmutable( $p_timestamp, new DateTimeZone( 'UTC' ) ); Is that 2nd param only a fallback, or is this setting UTC unconditionally?

Further down I see a MySQL < 8.0.19 workaround that does setTimezone( new DateTimeZone( 'UTC' ) ). Maybe this is screwing the timezone?

[seanm]

I added similar logs to the SourceSVN plugin, and it's interesting to contrast the results. There the date I receive is 2025-10-30T17:33:29.900156Z, meaning it's already in UTC. Whereas with gitlab, it seems to come in local time. And recall mantis shows correct dates for svn and wrong dates for gitlab. So maybe this is the relevant difference.

[seanm]

@dregad friendly ping...

[dregad]

Sorry I'm quite busy these days, did not have time to look into this until now

2025-10-29T15:59:48.000-04:00. i.e. it's getting local time from gitlab (if I understand this right). Is this expected?

Well the expected is whatever the GitLab API is sending...

Here we indeed have a local time, but since the timezone is specified we can calculate UTC: 15:59 + 4 = 19:59 UTC, which PHP's DateTime library does for us.

In SourceChangeset's __construct, I see $t_timestamp = new DateTimeImmutable( $p_timestamp, new DateTimeZone( 'UTC' ) ); Is that 2nd param only a fallback, or is this setting UTC unconditionally?

The 2nd parameter will consider $p_timestamp to be in UTC time, if it does not already include timezone information (otherwise it is ignored)^1.

MySQL < 8.0.19 workaround that does setTimezone( new DateTimeZone( 'UTC' ) ). Maybe this is screwing the timezone?

It shouldn't, it just makes sure the subsequent format() call which cannot include TZ info due to MySQL limitation, is actually a UTC time, which is then stored in the database.

$p_timestamp = '2025-10-29T15:59:48.000-04:00';

$t_timestamp = new DateTimeImmutable( $p_timestamp, new DateTimeZone( 'UTC' ) );
echo $t_timestamp->format(DATE_ATOM);
# 2025-10-29T15:59:48-04:00
#                     ^ original timezone was kept

$t2 = $t_timestamp->setTimezone( new DateTimeZone( 'UTC' ) ) );
echo $t2->format(DATE_ATOM);
# 2025-10-29T19:59:48+00:00
#            ^        ^ timezone changed
#            +- time converted to UTC

Doing the same exercise for the SVN timestamp shows that the generated date string for database insertion is also in UTC.

$p_timestamp = '2025-10-30T17:33:29.900156Z';
$t_timestamp = new DateTimeImmutable( $p_timestamp, new DateTimeZone( 'UTC' ) );
$t2 = $t_timestamp->setTimezone( new DateTimeZone( 'UTC' ) ) );
echo $t_timestamp->format(DATE_ATOM);
# 2025-10-30T17:33:29+00:00
echo $t2->format(DATE_ATOM);
# 2025-10-30T17:33:29+00:00

This all seems normal and works-as-designed to me.

When displaying changesets, the Source plugin reads the timestamp from the database (which it expects to be UTC) and converts it to the user's configured timezone (see SourceChangeset::getLocalTimestamp() method).

mantis shows correct dates for svn and wrong dates for gitlab. So maybe this is the relevant difference.

It is a possibility, and indeed it could justify the 4 hours difference. However, I believe I have demonstrated that the time is (or at least should be) consistently stored as UTC in the database.

So at this point I am unable to explain the behavior you describe.

Maybe you could check how the timestamp is stored in your DB vs the original commit time, for SVN and GitLab ? Does the stored time change depending on the user, system or process to record the changeset ?

It would be also interesting to check what the database's timezone is (see https://stackoverflow.com/a/19069310/1045774).

For the record, I use neither SVN nor Gitlab.