The custom formats "%X" and "%c" display the time including seconds, but the datetime plugin is not updated every second. Reproduce by configuring the plugin with a "Date, then time" layout, the first standard date format in the date format menu, and "%X" as the custom time format. This custom time format shows seconds, but the plugin is not updated every second. The updates occur every 10 seconds instead. Next configure the date with the custom format "%c", the time with the first format in the time format menu (23:59). The "%c" format displays seconds, but the plugin is not updated every second. Finally, change the time format to one that includes seconds (23:59:59). Now both the date and time fields are updated once a second. The locale is en_US (both "%X" and "%c" are locale specific). Version is trunk rev 4846.
Indeed, I was easily able to reproduce the issue. In datetime_apply_format, there is: if (strstr(datetime->date_format, "%S") != NULL || strstr(datetime->date_format, "%s") != NULL || strstr(datetime->date_format, "%r") != NULL || strstr(datetime->date_format, "%T") != NULL || strstr(datetime->time_format, "%S") != NULL || strstr(datetime->time_format, "%s") != NULL || strstr(datetime->time_format, "%r") != NULL || strstr(datetime->time_format, "%T") != NULL) As you observed, that's missing at least %c and %X.
Created attachment 1644 possibly overkill fix Here's a patch that will solve this issue - no matter what new format specifiers are introduced in the future or included in another OS. I'm wondering if it's overkill, though, for this purpose. Your thoughts?
(In reply to comment #2) > Created an attachment (id=1644) [details] > possibly overkill fix > > Here's a patch that will solve this issue - no matter what new format > specifiers are introduced in the future or included in another OS. I'm > wondering if it's overkill, though, for this purpose. Your thoughts? That looks good and doesn't seem like overkill. The test is robust and occurs only when the plugin properties change. Updates do not occur every second with the '%s' specifier. Increasing the tm_year field to 100 (70 would probably work) results in updates every second. I believe the time conversion was failing because the year 1900 cannot be represented as a number of seconds since 1970. - .tm_year = 0, + .tm_year = 100, Your approach solves another problem -- the specifier '%%s' produces '%s', which does not change, yet results in updates once a second using the current approach. Confirmed with powertop (http://www.lesswatts.org/projects/powertop/). Can you think of any reason why the longer update interval couldn't be 60000 instead of the current 10000?
(In response to Comment #3:) OK, you've convinced me that it's not overkill. I hadn't even considered the %%s case. I'm fine with bumping the year up by to 2000 (.tm_year=100), that seems like it would be at least as portable. I had asked on IRC about the 10s timer rather than 60s. Here's the excerpt: 01-05-2008 21:49:45 > ongardie: that's curious, datetime has a 1000ms timeout when the seconds are displayed, but a 10000ms timeout for minutes 01-05-2008 21:50:05 > ongardie: changing it to 60,000ms works fine 01-05-2008 21:53:07 < kelnos: ongardie: right, but then the clock could be 59 seconds off 01-05-2008 21:54:04 > ongardie: kelnos: 59s off vs 9s off? 01-05-2008 21:54:23 < kelnos: yeah... 01-05-2008 21:54:31 < kelnos: that's a bit of a difference 01-05-2008 21:54:36 < kelnos: not really a big deal, but... yeah 01-05-2008 21:54:45 > ongardie: meh, i suppose so
(In reply to comment #4) > I had asked on IRC about the 10s timer rather than 60s. Here's the excerpt: ... > 01-05-2008 21:53:07 < kelnos: ongardie: right, but then the clock could be 59 > seconds off > 01-05-2008 21:54:04 > ongardie: kelnos: 59s off vs 9s off? ... Thanks for providing this excerpt. The latency is a noticeable and annoying effect, so I have opened bug 4119. The basic problem is that the plugin is polling (or sampling) the system clock instead of *synchronizing* with it.
Re Comment #4, thanks for moving that to a different bug report. Attachment 1644 became revision 4859. The tm_year=100 change followed in revision 4860.
Created attachment 1655 use 1970 instead for clarity; copyedit comments I believe it would be more clear to use the year 1970 in datetime_gtimeval_to_ms(). (I was thinking that code for the year 2000 would be well-tested, but that is only a supposition.) This patch also rewords some of the comments. Could datetime_gtimeval_to_ms() use guint64 instead of gint64? Patch is against trunk.
(In reply to comment #7) > Created an attachment (id=1655) [details] > use 1970 instead for clarity; copyedit comments ... > Could datetime_gtimeval_to_ms() use guint64 instead of gint64? ... Looked at this closer. Signed values are used so that times before the epoch 1970 can be represented as negative numbers. $ date +%s -u -d 'jan 1 1970 00:00:00' 0 $ date +%s -u -d 'dec 31 1969 23:59:59' -1 Interestingly, 1900 and 1901 cannot be so represented, but 1902 can be. $ date +%s -u -d 'jan 1 1900 00:00:00' date: invalid date `jan 1 1900 00:00:00' $ date +%s -u -d 'jan 1 1901 00:00:00' date: invalid date `jan 1 1901 00:00:00' $ date +%s -u -d 'jan 1 1902 00:00:00' -2145916800
Committed attachment 1655 as revision 4868.