strftime doesn't honor the charmap. The following shows that strftime
yields ISO-8859-1 characters while the charmap is UTF-8.

$ locale
LANG=POSIX
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=fr_FR
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
$ locale charmap
UTF-8
$ date -d 2015-02-07 +%b
f�vr.
$ date -d 2015-02-07 +%B
f�vrier
$ date -d 2015-02-07 +%B | hd
00000000  66 e9 76 72 69 65 72 0a                           |f.vrier.|
00000008

Note that there is no such problem with LC_MESSAGES, e.g.:

$ LC_MESSAGES=fr_FR cp
cp: opérande de fichier manquant
Saisissez « cp --help » pour plus d'informations.

is UTF-8 as expected.

Le 23/09/2015 12:17, Vincent Lefevre a écrit :

  ^^^^^^^^^^^^^
LC_TIME is set to fr_FR, that is latin1.
If LC_TIME is set to fr_FR.utf8, I cannot observe the problem anymore.

$ LC_TIME=fr_FR date -d 2015-02-07 +%b | hexdump -C
00000000  66 e9 76 72 2e 0a                                 |f.vr..|
00000006
$ LC_TIME=fr_FR.utf8 date -d 2015-02-07 +%b | hexdump -C
00000000  66 c3 a9 76 72 2e 0a                              |f..vr..|
00000007

  If you agree with me, I let you close the bug.

  Regards,
    Vincent

I disagree. The charmap is specified by LC_CTYPE, not by LC_TIME.
See the locale(7) man page:

  LC_CTYPE
    This category determines the interpretation of byte sequences
    as characters (e.g., single versus multibyte characters), [...]

  LC_TIME
    This category governs the formatting used for date and time
    values. For example, most of Europe uses a 24-hour clock
    versus the 12-hour clock used in the United States. [...]

So, the charmap part of the locale value of LC_TIME should be ignored,
just like it is for LC_MESSAGES (with LC_MESSAGES=fr_FR in a UTF-8
environment, messages are output in UTF-8, even though fr_FR is
latin1).