bug#11843: date -s vs encoding bug.

[Jim Meyering]

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<-----------------------------
> address@hidden  ntpdate ntp.server
>  2 Jul 16:14:04 ntpdate[18848]: adjust time server 1.2.3.4 offset -0.002628 
> sec
> address@hidden date
> 2012年  7月  2日 月曜日 16:14:10 JST
> address@hidden date -s "`date`"
> 2012年  7月  2日 月曜日 20:12:00 JST
> address@hidden 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.