v0.8.1
Dates now say which timezone they're in
Notification email timestamps ({{timestampFormatted}}) rendered a bare date and time with
nothing to say whether it was the recipient's time, the server's, or UTC:
When: 11 Sept 2026, 1:47 pm
Every rendered date and time now names the zone:
When: 11 Sept 2026, 1:47 pm Australian Eastern Standard Time
The full name is the default because it renders identically no matter the recipient's
locale. If you'd rather have something shorter, email.timeZoneNameStyle picks a
different style:
email: {
timeZoneNameStyle: 'short', // default: 'long'
},
| Style | Example (Australia/Sydney, recipient locale en-AU) |
|---|---|
'long' (default) | Australian Eastern Standard Time |
'short' | AEST |
'shortOffset' | GMT+10 |
'longOffset' | GMT+10:00 |
'shortGeneric' | AET |
'longGeneric' | Australian Eastern Time |
'short'/'shortGeneric' only render a colloquial abbreviation like AEST when the
recipient's own locale matches the region their timezone belongs to — otherwise they
fall back to a generic offset, since there's no way to force one abbreviation regardless of
locale (and most aren't unambiguous across regions anyway — CST alone means three
different things). See Configuration.
Admin-initiated reset links can prepopulate the email field
AdminAuthService.resetPassword()'s link now carries the user's email alongside the code:
https://myapp.com/reset-password?code=123456&email=user%40example.com
so your reset-password page can prepopulate the identifier field instead of asking the user
to retype the address the code was just sent to. Self-service forgotPassword links are
unchanged — the admin already has the target address on hand, since it's initiating the
reset on the user's behalf.
This also gives a frontend handling both link types something to key off: the self-service
link never carries email. See Admin Operations.
Fixed: cookies left behind after logout under a custom prefix
If your cookieNamePrefix followed the documented convention of already including its
trailing separator (e.g. myapp_), logout, "forget me", and "forget device" cleared the
access, refresh, device-token, and default-named CSRF cookies under a name with an extra
underscore that was never actually set — myapp__access_token instead of
myapp_access_token — so the real cookies stayed in the browser.
This only affected the cookies themselves — the session was correctly revoked server-side, so a lingering cookie could not be used to make an authenticated request. Only Express-based deployments were affected; Fastify was always correct.
No action needed — the fix takes effect on upgrade.