Dana Diederich wrote:
This is a related but different question/comment.
In the six or so years of using MySQL, my various teams have never used
anything except an unsigned INT and UNIX Epoch time to record timestamps.
The given is, of course, we have always been a Perl/C/C++/UNIX shop, and we
Dana Diederich wrote:
Can anyone share and/or comment about the use of Epoch time, especially the
hazards? I'm asking because I want to make sure that I haven't built a
comfortable little box that un-necessarily excludes some useful functions.
I use Epoch time myself, except where I use
Csongor Fagyal wrote:
Oh and one more thing I am not really sure of: sometimes defining the
day as 3600*24 or the year as 3600*24*365 is not the best idea... just
think about leap years. How do you handle that? And there are some
more artifacts in the Gregorian calendar, too...
But MySQL
Can anyone share and/or comment about the use of Epoch time,
especially the hazards?
Using timestamps you can synch all your times with the server via
'now()' and the like. If you use the epoch time on the client side you
might have problems. What those problems are, I couldn't say- but I
I personally prefer TAI64 time (sub-second precision; see
http://cr.yp.to/libtai/tai64.html). For a comparison of how this
differs from UNIX time, see http://cr.yp.to/proto/utctai.html at the
same site. I'm surprised SQL hasn't been updated to support new time
formats yet, but oh well.
Csongor Fagyal wrote:
I personally prefer TAI64 time (sub-second precision; see
http://cr.yp.to/libtai/tai64.html). For a comparison of how this
differs from UNIX time, see http://cr.yp.to/proto/utctai.html at the
same site. I'm surprised SQL hasn't been updated to support new time
formats
