I want to store a Carbon date time object in a MySQL Database and I am using Laravel Eloquent to do this.
I have build a test with different data types (dateTime, dateTimeTz, timestamp and timestampTz from Laravel Migrations) and every one cuts off the time zone and only stores the date and time. When the data is accessed again Laravel assumes the default time zone from config and I have invalid data.
Is there a way to either preserve the time zone or to automatically convert the date and time to UTC or the config time zone?
MySQL doesn't provide any features to store Timestamp with Timezone. You have to separately maintain all the timezone manually.
You can define seprate column for maintaining the timezone when the Timestamp retrieved from the Database you can convert Timestamp to related Timezone.
For that you can use Laravel features Accessors.
Related
I am using timestamp fields in my databases and my PHP software has its own time management system based on users timezone. I want to use timestamp fields for certain kind of data (created or modified when) and also be able to use te DEFAULT CURRENT_TIMESTAMP for the columns.
Is there any disadvantage setting the timezone to UTC using, SET time_zone = '+00:00', each time the session is created. I have four separate databases which the software uses and currently, I am setting the current timezone to UTC.
I don't want to use DATETIME as they are larger in size and also I won't be able to use DEFAULT CURRENT_TIMESTAMP as the timezone of the server might have an offset.
You should not use SET time_zone if your backend already uses all the logic into converting user's timezone correctly, because you're wasting resources unnecessarily. The UTC timezone should be into the metadata of the DB, where always the DB transactions will work with them.
By the way, TIMESTAMP columns always will be stored in UTC, so you don't need to setting that, unless your columns are datetime (not the case, i think).
When you insert a TIMESTAMP value, MySQL converts it from your
connection’s time zone to UTC for storage. When you query a TIMESTAMP
value, MySQL converts the UTC value back to your connection’s time
zone. Notice that this conversion does not occur for other temporal
data types such as DATETIME.
So you have two options:
Set the timezone in your transactions working with time in your sql;
Working with unix timezones into backend and only showing the correct converted time in the frontend to user.
I prefer the second one.
When dealing with date/time for entry date and/or modified date, it is better to use normal VARCHAR with the length of around 200 (or any other value that fits the full date) in order to store the full date and process your date/time in your PHP script. This gives you the flexibility to view your time based on the timezone defined in your PHP code. Click here to see available timezones in PHP.
You can also format the date/time in any possible format you want by simply using the date_format of PHP.
I have given a reference code below.
//This is the way you define your timezone in PHP code
date_default_timezone_set('Asia/Beirut');
//You can capture the date/time by using the below code. This will store "2017-05-28 23:55:34"
$date_time_registered = date('Y-m-d H:i:s');
//Retrieve the date/time and re-format it as you require. Below code will output "May", full month.
$retrieve_month_only = date_create($row['your_store_date_time']);
$retrieve_month_formatted = date_format($retrieve_month_only, 'F');
echo $retrieve_month_formatted;
You can refer to this link to find out about PHP date/time formatting.
I am using symfony 3 and doctrine for my new project. When generating new entity what is best time format to select? datetime, datetimetz, date, time?
My main activity with time will be used for logging events (modified_at, created_at and etc.)
How to select the right one for MySQL database? I am planning to do time calculations in future. Any recommendations?
Depends on how you want to use timezone in your system. For example. Symfony has a terminology of :
Model Timezone : The timezone that associated with database and system.
View Timezone : The timezone that is used for end user. (Useful, for applications built for different timezone.)
The best options would be, to follow a standard to store all date_time in UTC timezone in your database which will not require to save a timezone along with the date_time.
When you fetch data for end user, you can always convert dates as per View Timezone.
Regarding your question (format of datetime):
If your data needs only date to deal with. You should use date field type. Else you can go with datetime or timestamp, if you are considering above options to manage timezone.
Else, if you have to store timezone along with your data, datetimetz might be a solution.
I've been studying the differences in usage between MySQL's DATETIME and TIMESTAMP. It seems that it's pretty straight forward with DATETIME. I would use the following procedure:
Choose the default timezone for all dates, such as UTC.
Let user select a date from drop-down.
Create new PHP DateTime object with the chosen date, using the user's timezone settings, such as EST.
Convert the object to UTC, and insert into database.
On another page, retrieve datetime value and make a new DateTime object with it, using UTC timezone.
Convert object to user's local time (EST), and display to him.
Now, it seems that mysql's TIMESTAMP column type can help eliminate all of these conversions.
What would the above steps look like with the TIMESTAMP column type?
Would I need to do "SET time_zone = timezone;" in the beginning of each pageload to set the timezone to the location of the user?
Would it be easier to ONLY use one type of date column type per database? If not, it may require two different sets of functions to produce the right date.
Should TIMESTAMP only be used in columns not intended to be shown to the public (so as not to deal with formatting)? Like when a row was created, last edited, etc.
I have not tested any of this approach, but it seems pretty straightforward =)
You shouldn't need to convert dates, just set the time zone when you
read/write from dB to get everything right.
Yes, you will have to set right time zone after connection to dB is made.
You mean to only use datetime or timestamp? It really depends on how you intend to
use the columns. But there isn't a clear have to do.
Same as above, it isn't wrong formatting your data from the dB, with a timestamp you can return date style strings from the dB so no worries
Traditionally timestamp is associated like you mention, and datetime for other dates.
more on locale/time zone:
MYSQL set timezone in PHP code
There's lots of recommendations out there about handling dates. I'd just like to clarify something. Let's say:
user is inserting records into a database
unix timestamps of insertion date are generated for this record
Now the user wants to query a date interval in the database:
user provides 2 dates in his local timezone
use these values to convert timezone to UTC and get the timestamp
query the records in the database based on the 2 integers from conversion (eg. WHERE date >= FIRST and date <= SECOND)
convert the retrieved timestamps to local timezone again for display
I know that would be possible with PHP, but and wouldn't need to care about mysql's timezone settings in this case - only php's. The system would be 64 bit so running out of space to store the date is not an issue. But ...
Would that raise any other serious issues like with DST changes or something else?
Unix timestamp is timezone-independent.
This is also the reason you can change this step:
use these values to convert timezone to UTC and get the timestamp
into this:
convert values to Unix timestamp
Although storing timestamps in the database (eg. MySQL) is very simple. You can make sure PHP has Unix timestamp, if you will:
save the values by using FROM_UNIXTIME() MySQL's function (give Unix timestamp as argument and you will receive datetime according to MySQL's settings),
retrieve the values by using UNIX_TIMESTAMP() MySQL's function (give the name of the field, or the value, as the argument), so you will get Unix timestamp (integer) on the basis of datetime stored in the database according to MySQL's settings.
Just remember to use TIMESTAMP column type to store timestamps. This way the time will be stored in timezone-independent manner, only displayed according to MySQL's settings.
Tadeck is correct that Unix timestamps are timezone-independent.
But when using timestamps throughout your application you should store and use timestamps in the database as plain INTs. Convert to and from local timezones at the application level (in PHP). That allows you to only concern yourself with timezones in PHP and not in 2 systems. It also eases setting time zones for individual users at the application level.
Question: How do I Display a UTC timestamp from a database table in a users local time? Is there any way to do this with php?
Extra Context \/
I have an application that saves the date records are added to the database.I am saving the records in the database using mysql UTC_TIMESTAMP(). I then want to display the record to the user in their local time in my Smarty template.
{$dateAdded|smarty_modifier:"%D %R %Z"}
I have tried smarty, date_format as the modifier but I just get the UTC time and the persons timezone, which of course is correct but not the result that I want.
02/11/11 20:32 Pacific Standard Time
I need the time so be set to the user's local time
02/11/11 12:32 Pacific Standard Time
Is it correct to store the date of the transaction in UTC, and how do I display that UTC to the user in their local time? Is there a way to pull the date out of the database so that it is set to the users current local time?
You can use date_default_timezone_set() prior invoking the Smarty template. That defines directly how the UTC timestamps are adapted to the expected output timezone.