peter evans wrote:
> Operating system is redhat 6.1
> Version of coreutils is 8.4 according to yum.
>
> System LANG is set to:
> LANG=ja_JP.UTF-8
>
> -------8<-----------------------------
> [root@x]# ntpdate ntp.server
> 2 Jul 16:14:04 ntpdate[18848]: adjust time server 1.2.3.4 offset -0.002628
> sec
> [root@x]# date
> 2012年 7月 2日 月曜日 16:14:10 JST
> [root@x]# date -s "`date`"
> 2012年 7月 2日 月曜日 20:12:00 JST
> [root@x]# ntpdate ntp.server
> 2 Jul 16:14:15 ntpdate[18856]: step time server 1.2.3.4 offset -14268.134688
> sec
> -------8<-----------------------------
>
> date -s "whatever" is mis-interpretting what it was fed.
Thanks for the report, but this is not a bug in GNU date.
date is not expected to parse arbitrary locale-dependent strings.
To get the behavior you want (a nominally no-op date-setting command),
you should use this instead:
date -s "$(date '+%F %T.%N')"
That works because the inner date's output format is independent of the
current locale.
Note the use of %N (nanoseconds).
Without it, you're setting the clock back by up to one second.
It's not a big deal if you're about to correct with ntpdate,
but it's best to minimize unnecessary jumps like that.
P.S., to readers, setting the date like that happens to work around
a kernel bug triggered by the recent leap second insertion.
Symptom: unusually high CPU usage by futex/mutex-using processes.
Common offenders: firefox, mysqld, thunderbird.
