23 Apr
2013
23 Apr
'13
11:50 p.m.
Hello,
On 4/23/13 9:44 PM, Andreas Granig wrote:
I see your point related to datetime format for time column.
Still pondering why limit to milisecs when having access to microsecs --
might not be a requirement of such precision in any country, but could
be used for stats or even someone will request it at some point in
future. So I would rather add two columns with secs and microsecs. Now
thinking that using one column with type double might create troubles to
some db drivers -- the pros are safe with db drivers and no issues in
float/double type precision, the cons is using two columns to get duration.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
[...]
the result was reading quite strange, though.
- the names of the new column, respectively
'time_hires' sounds a bit
strange to me, does it have any special meaning the word 'hires'?
It's "hires" as in "high resolution" for the timestamp value.
Overall, wouldn't be better to keep the
seconds and microseconds (as
returned in a timeval structure) in separate columns. That means keeping
the time column as it is and adding a new column for microsecs. Then
people can get the precision as they want, including only down to the
miliseconds if that is what they need.
The time column is still being filled as usual, so you can just stay
with that format. However, the problem with this column is its
date-time format, which causes lots of problems for calls going over
daylight saving time changes and when it comes to handling different
time zones in general, so time_hires uses a unix-timestamp with 3
digit precision, which makes this much easier to handle. And then
again, if you want to use the time_hires column, you can still do
from_unixtime in mysql to get a normal datetime format in seconds
precision, no need to handle seconds and milliseconds separately.