[support] How to store/retreive date fields into/from MySql
Doug du Boulay
doug.duboulay at gmail.com
Tue Mar 29 06:23:18 UTC 2011
On Tue, 29 Mar 2011, Carl Wiedemann wrote:
> If you are storing birthdates, you probably want to use DATETIME in the
> schema instead of INT. INT would require the date be stored as a unix
> timestamp, which is only valid after the year 1970, and birthdays are
> likely to exist before this date.
From wikipedia: http://en.wikipedia.org/wiki/Unix_time
"The Unix time number is zero at the Unix epoch, and increases by exactly 86
400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12 677 days after the
epoch, is represented by the Unix time number 12 677 × 86 400 = 1 095 292 800.
This can be extended backwards from the epoch too, using negative numbers;
thus 1957-10-04T00:00:00Z, 4 472 days before the epoch, is represented by the
Unix time number −4 472 × 86 400 = -386 380 800."
and
"The standard Unix time_t (data type representing a point in time) is a signed
integer data type, traditionally of 32 bits (but see below), directly encoding
the Unix time number as described in the preceding section. Being 32 bits
means that it covers a range of about 136 years in total. The minimum
representable time is 1901-12-13, and the maximum representable time is
2038-01-19. At 03:14:07 UTC 2038-01-19 this representation overflows. This
milestone is anticipated with a mixture of amusement and dread; see year 2038
problem."
I looked into this issue once myself and decided that the advantages of
adding and subtracting integers and applying SQL intdate<threshold tests
on the database server was far easier/more efficient to manage than comparing
strings.
And also, I'll be retired by 2038. Someone elses problem!
More information about the support
mailing list