Question
AdonisJS v5: Global Timezone Config vs. Lucid Date Serialization
Dev Byte
0 reputation · 23 Jul 2026, 01:39 UTC
94.2K views1
Loading…
0 reputation · 23 Jul 2026, 01:39 UTC
The primary objective is to guarantee that date values stored in the database, cast by Lucid, and exposed through API responses all reflect the same regional time zone defined in the framework’s global configuration.
AdonisJS v5 ships with Luxon integration, and the config/app.ts file exposes a 'timezone' key that influences date parsing and formatting. However, the default datetime cast converts database values to Luxon DateTime objects, and when the model is serialized to JSON it emits UTC timestamps unless overridden.
Because there is no automatic middleware that adjusts incoming request date strings to the configured timezone, developers must manually convert dates before persisting or responding. The interaction between the global timezone setting, the database’s timestamp columns, and the JSON output remains undocumented, leaving uncertainty about the actual behavior.
1. Does setting config/app.ts 'timezone' affect the output of Lucid’s datetime cast when serializing models to JSON, or does it always default to UTC?
2. If the global timezone is respected during parsing, how does it interact with database drivers that store timestamps in UTC?
3. Is there a recommended pattern for converting request‑side date strings to the configured timezone before saving?
35275 reputation · 23 Jul 2026, 04:29 UTC
1. Does the config/app.ts timezone affect Lucid’s datetime cast when a model is serialized to JSON?
No. The global timezone key only sets Luxon’s defaultZone for helper utilities. Lucid’s built‑in datetime cast always creates a Luxon.DateTime object that is internally normalized to UTC. When model.toJSON() is called, the cast uses toISO() (or toJSON()), which emits an ISO string ending with Z. The configured zone is not applied automatically.
2. If the global timezone is respected during parsing, how does it interact with database drivers that store timestamps in UTC?
When you explicitly parse an incoming date string with the configured zone, you should immediately convert the result to UTC before assigning it to the model attribute. Lucid will then persist that UTC value. The database driver receives a UTC timestamp string (most drivers return plain strings without a zone). Because the database itself stores timestamps in UTC, the round‑trip preserves the original moment but remains zone‑agnostic. The global timezone does not influence the driver’s storage format.
3. Recommended pattern for converting request‑side date strings to the configured timezone before saving.
adonisjsconst tz = Config.get('app.timezone') (e.g., 'America/New_York').const local = DateTime.fromISO(req.input('date'), { zone: tz }).const utc = local.toUTC() (or local.toISO({ format: 'basic' }) if the driver expects a string).Model.create({ startAt: utc }).For responses, you can override $serializeDates in the model or apply a getter that shifts the UTC value back to the configured zone before the JSON string is produced.
Do you use a database driver that enforces a session timezone (for example, PostgreSQL’s SET TIME ZONE at connection time)? That setting can alter the string that the driver returns to Lucid, which would affect the parsing logic above.
console.log(Config.get('app.timezone')).model.createdAt.zoneName – it should be utc.console.log(JSON.stringify(model)) – the timestamp should end with Z.2026‑10‑17T22:40:39.496Z).Running these checks will confirm that the framework behaves as described and that your application’s timezone configuration is not being applied automatically to model serialization.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.