System Information
- Strapi Version: 3.3.3
- Operating System: Ubuntu
- Database: Mysql
- Node Version: v14.15.0
- NPM Version: 6.14.8
- Yarn Version:
Why the date is not 2020-11-17?
I’m going to guess you are in the Timezone GMT+8. Server backends work in UTC/GMT, so you set the time in your own local timezone and Strapi converts it to UTC to save in the database.
It will provide the UTC expecting your frontend to convert it to the users timezone. It’s better to handle this conversion client-side as the client is the most trustworthy about what it’s timezone is.
Server backends, including databases, should always always always work in a single standard timezone, typically UTC or GMT+0
1 Like
Hi, i have the same problem, and my server work on GMT -3.
I setup in database.js the option timezone: ‘GMT -3’.
All the tables are legacy , not created with Strapi. I’m using this as a REST API server.
I have two fields, on of type “date” ,in the DB(mysql) and Strapi, and works fine.
In the same table have another field type DATETIME, I created as type “string” in Strapi, when I get the endpoint I get Zulu Format time : update_at: “2020-11-26T01:32:56.000Z” …
Why is because of the name ( _at ) ? and why is calculating time zone utc 0 ?
Best Regards
See: Strapi’s documentation | Strapi Documentation
timezone(string): Set the default behavior for local time. Default value:utc
And these are the options to modify that: PHP: List of Supported Timezones - Manual
Again to you and others that find this via search: It is never a good practice to set your database timezone to something other than UTC!
Hello, for me, the default timezone database setting did not work even if I set it explicitly in the database connection config in config/database.ts with Strapi V4 and postgresDB
What works, at least for the most important part: storing date in database as UTC is:
TL;DR
Set an environment variable TZ=UTC in your .env file
However, the Strapi admin client is still showing me zoned dates frontend side even if the network response contains UTC dates.
1 Like
Hey, it’s not about setting the database timezone to a different timezone, it’s about usability. The admin user not necessarily is located in UTC-0, so the admin console which is a client app running in the ‘user admin side’ needs to make sure the date he/she is setting actually corresponds in DB with the right timezone.