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.
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 new in php and I saw some programmer store datetime in database by php date() or mysql NOW() or take column as timestamp. I want to know that the difference between these three is and also how to convert these three formats to users local time worldwide.
As per the mysql's law you can have only one timestamp field,no
restrictions for having number of datetime field..
You can set the
timestamp field for onupdate current timestamp or current
timestamp..And these field type not affecting the date insert
method..
If you are using date() function you can set your own
date format..But not in the now()
For date format the syntax check this article https://www.w3schools.com/php/func_date_date.asp
Finaly Datetime and timestampis mysql
date() and NOW()is php
There's a few things to consider:
TIMESTAMP columns are limited to dates between 1931 and 2038, as they're 32-bit timestamp values.
DATETIME columns can go up to the year 9999. While they don't auto-populate like TIMESTAMP values do by default, they're less restricted, you can have as many as you want per table.
When inserting times your PHP clock and your database clock might differ slightly. Using NTP can help narrow that gap, but drifts do happen. PHP's date() function requires formatting into ISO-8601 format for inserting (YYYY-MM-DD HH:MM:SS). The MySQL NOW() function does not, same with UTC_TIMESTAMP().
I strongly recommend using UTC time in your database for a few reasons:
If you store in local time you'll need to store the time-zone as well, and those can change in wild and bizarre ways.
You may need to accommodate other time zones in the future, which means you might have multiple local times in your data where each record might have a different meaning from others.
Your server might get moved between time-zones which can shift all your data.
So store with UTC and render out as local times based on the user's time-zone preference or some sensible default for your application. Remember, time formatting is often a fussy thing, every country has different date formatting standards, and even a single country might have multiple preferences for long-form, short-form, or numerical forms.
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.
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
Does anyone know what would be the right type of a MySQL column in order to store the date in the following format? Ex: 2012-11-11T11:09:28+00:00
Update:
The part I was interested in was how to store the timezone +xx:xx of the user that took the action and the question was if there's is a MySQL date format that would include the timezone as well. Read the MySQL docs and didn't find any relevant information, that's why I wrote here.
There's no DATE/TIME column type in MySQL that includes the timezone. It's also not really necessary, since a timestamp is a timestamp, it's an absolute point in time. The timezone is only relevant if you want to format the timestamp as a local time, but MySQL stores dates as absolute points in time, regardless of timezone.
If you want to store a value including timezone information, you'll have to store it as a string.
But, the better strategy is this anyways:
normalize all times in your application to one timezone, UTC being a good choice
store that normalized time in the database
store a user preference for his/her preferred timezone
when fetching times from the database to display, convert them from UTC to the desired timezone of the user
That's the typical way to handle this. You can also store a timezone in another column next to the timestamp column, if that makes sense for your app:
`time_utc` (DATETIME) | `timezone` (VARCHAR)
----------------------+---------------------
2012-11-11 11:11:11 | Europe/Berlin
This way you have unified timestamps in your database to do calculations/queries on, while being able to format them in a local time when needed.