Hello,
On 4/23/13 9:44 PM, Andreas Granig wrote:
[...]
- 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.
the result was reading quite strange, though.
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.
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