MySQL chooses the right way to store time

Building a database writer cannot avoid using the date and time. For the database, there are a variety of date and time fields to choose from, such as timestamp and datetime, and the use of int to store unix timestamp.

Not only novices, but also some experienced programmers are still confused. Which type should I use to store date and time?

Then we will analyze their characteristics step by step, so that we choose the appropriate field type to store according to our own needs (the advantages and disadvantages are compared, like parents like to take neighbors and children to compare with themselves)

datetime 和 timestamp

1. Datetime is more like the combination of the time on the calendar and the time of your watch, which refers to a specific time.
2. estamp is more suitable for recording time. For example, my time in Dongba District is now 2016-08-02 10:35:52, you are in Japan (the time in Dongjiu District is 2016-08-02 11:35:52), I am chatting with you and the time is recorded in the database. After taking it out, the time is 2016-08-02 10:35:52 for me and 2016-08-02 11:35:52 for you in Japan. So there is no need to consider time zone calculations.
3. The time range is timestamp (1970-2038), of course, datetime (1000-9999) can not record when Liu Bei was born (161 years)

timestamp 和 UNIX timestamp

1. Intuitive display, easy to debug if something goes wrong, much better than many long int numbers
2. int has been accumulated since 1970, but the range supported by int is 1901-12-13 to 2038-01-19 03:14:07. If you need a larger range, you need to set it to bigInt. But this time does not include milliseconds, if milliseconds are needed, they also need to be defined as floating point numbers. Datetime and timestamp have 6 microseconds natively.
3. Timestamp is with its own time zone conversion, same as item 2 above.
4. The time entered by the user's front end is generally a date type, if you store int, you need to store it before fetch

to sum up

1. timestamp records frequently updated updates / create / post / log time / purchase time / login time / registration time, etc., and is recent time, enough time, automatic time zone processing, such as overseas purchases or business may expand overseas
2. The datetime records a fixed time, such as the time the server performs scheduled tasks / fitness exercise time, etc. In any time zone, a fixed time is required to do something. Time beyond timestamp, if you need a time zone, you must remember the time zone processing
3. UNIX timestamps is not very convenient to use, as for the scope of what, timestamp and datetime can do
4. If you don't consider the time zone, or have your own time zone plan, feel free to choose which one you like
5. laravel international framework is designed for the convenience of the programmer, database design standards in line, so created_at updated_atuse the timestamp is understandable.
6. Is there a time type that solves the problem of range and time zone? This is impossible, isn't there TinyInt BigInt? Take what you need, and MySQL allows database field changes.
7. Birthdays can be stored using multiple fields, such as year / month / day, so that users who have a birthday on a certain day can be easily found

When building a project, you need to think carefully about which one is more suitable for your business scenario. Which one to choose? Demand depends.