This is expected to make system debugging easier.
This raises two compatibility issues:
1. When a new ovsdb-tool reads an old database, it will multiply by 1000 any
timestamp it reads which is less than 1<<31. Since this date corresponds to
Jan 16 1970 this is unlikely to cause a problem.
2. When an old ovsdb-tool reads a new database, it will interpret the
millisecond timestamps as seconds and report dates in the far future; the
time of this commit is reported as the year 45672 (each second since the
epoch is interpreted as 16 minutes).
Signed-off-by: Paul Ingram <pingram@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Post-v2.0.0
---------------------
- - Log files now report times with millisecond resolution. (Previous
- versions only reported whole seconds.)
+ - Log file timestamps and ovsdb commit timestamps are now reported
+ with millisecond resolution. (Previous versions only reported
+ whole seconds.)
v2.0.0 - xx xxx xxxx
if (comment) {
json_object_put_string(json, "_comment", comment);
}
- json_object_put(json, "_date", json_integer_create(time_wall()));
+ json_object_put(json, "_date", json_integer_create(time_wall_msec()));
error = ovsdb_log_write(log, json);
json_destroy(json);
date = shash_find_data(json_object(json), "_date");
if (date && date->type == JSON_INTEGER) {
- time_t t = json_integer(date);
- char *s = xastrftime_msec(" %Y-%m-%d %H:%M:%S",
- t * 1000LL, true);
+ long long int t = json_integer(date);
+ char *s;
+
+ if (t < INT32_MAX) {
+ /* Older versions of ovsdb wrote timestamps in seconds. */
+ t *= 1000;
+ }
+
+ s = xastrftime_msec(" %Y-%m-%d %H:%M:%S.###", t, true);
fputs(s, stdout);
free(s);
}