The time field type is timestamp integer or time type.

No matter what the project is, you have to contact the time type. Currently, using timestamps to store date data (for integer storage) is already a common practice in the industry. Various online game companies and major open-source companies use integer timestamps for storage. There are many advantages for saving dates with integers. The program judges direct reading and has good scalability. It can convert xml, json, and other formats at will. However, the biggest drawback is that the database query is not intuitive. That is to say, when we open the database using management tools, we see a bunch of numbers, which makes it inconvenient to maintain data. To solve this problem, I found a method by first using the code:

Select *, DATE_FORMAT (FROM_UNIXTIME (datetimed/1000), "% Y-% m") from 'testtable'

TestTable is the table name, And datetimed is an integer field in the table. I am using millisecond storage, but mysql's FROM_UNIXTIME method can only be converted to seconds, so it is calculated in/1000.

If you have used Weaver dream, all open-source Discuz friends may have experienced a bunch of headaches and integer time. This mysql statement sticks to the management tool to run and you can see the date result intuitively.

 

However, if someone finds this troublesome, I have nothing to say. After all, some people do not need to consider expansion or use object format conversion for small projects. The operations in the background basically do not use Date. They convert Date to an integer before calculation. Why is it a waste of time and energy to save a Date type that is not easy to convert to the format. Timestamp is used by many large open-source platforms, which proves the advantages of Timestamp storage. Is this worth giving up expansion for a quick and intuitive purpose?