CMS shows incorrect time for users last login date

Joonas Kajava

Vote:

The CMS displays an incorrect Last login date/time for users because the CMS API appears to convert LastLoginDate to UTC even though the value is already stored in UTC in the database. This results in the displayed time being shifted (e.g., -2 hours).

I'm able to reproduce this bug easily.

When user logs in, their last login date is saved to database as UTC time.

The issue is that their last login date is shown as UTC time in the CMS:

The bug seems to originate from "/EPiServer/EPiServer.Cms.UI.Admin/users/GetUser?userName=bug" API which subtracts 2 hours from the last login (suggesting that this API treats already UTC time as local time):

CMS version: 12.34.1

#341587

Edited, Feb 02, 2026 9:49

Eric Herlitz

Vote:

Can you replicate this in multiple environments? E.g test, prod, your development box?

#341613

Feb 06, 2026 7:07

Joonas Kajava

Vote:

I can replicate this in local, test and production. Other projects also have this issue which suggests that this isn't project specific.

I've tried to change the timezone of the computer/server (and the db server), but that doesn't have any effect.

#341616

Feb 06, 2026 12:57

Eric Herlitz

Vote:

Just a thought, what coallition does your database use?

Check using

SELECT NAME, COLLATION_NAME FROM sys.Databases

#341664

Feb 11, 2026 14:30

Joonas Kajava

Vote:

It uses `SQL_Latin1_General_CP1_CI_AS`.

#341672

Feb 12, 2026 7:51

Keshav Dave

Vote:

This is not related to database collation (SQL_Latin1_General_CP1_CI_AS) and changing server/database timezone will not fix it.

In Optimizely CMS, LastLoginDate is stored in UTC (correct). However, the /EPiServer/Cms.UI.Admin/users/GetUser endpoint returns the value after it has been converted using the server’s local DateTimeKind

If the stored value is already UTC but is treated as DateTimeKind.Local before serialization, .NET will apply an additional UTC conversion — resulting in the time shift (e.g., −2 hours depending on server timezone).

Workaround options:-

Intercept/override the admin API response and explicitly set:

DateTime.SpecifyKind(lastLoginDate, DateTimeKind.Utc)

Or convert explicitly before returning:

#341703

Edited, Feb 15, 2026 20:06