Bug 45896 - [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
Summary: [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.3
: P4 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 71556 89778 99439 (view as bug list)
Depends on:
Blocks: 86976
  Show dependency treegraph
 
Reported: 2010-10-05 16:11 UTC by Alexander Rojas
Modified: 2021-12-10 16:20 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-03-20 00:00:00


Attachments
preprocessed file (73.24 KB, text/plain)
2010-10-05 16:16 UTC, Alexander Rojas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Rojas 2010-10-05 16:11:34 UTC
I just create a simple program to exchange dates formats based in locales. According to the standard ( http://www.opengroup.org/onlinepubs/9699919799/functions/strptime.html ) a date like 2/2/2005 would be a valid date. However the program fails with that input. It requires 02/02/2005 to work.

The compiler options where set to:
g++ -v -save-temps -odate date.cpp

the program compiles without errors or warnings.

This is the dump of my system information:


Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE date.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -fstack-protector -o date.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.4
 /usr/include/c++/4.4/x86_64-linux-gnu
 /usr/include/c++/4.4/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -fpreprocessed date.ii -quiet -dumpbase date.cpp -mtune=generic -auxbase date -version -fstack-protector -o date.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
        compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
        compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 88858f45841827736473e527a4e9ab10
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc' '-mtune=generic'
 as -V -Qy -o date.o date.s
GNU assembler version 2.20.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/collect2 --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -odate -z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../.. -L/usr/lib/x86_64-linux-gnu date.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crtn.o
Comment 1 Alexander Rojas 2010-10-05 16:16:04 UTC
Created attachment 21966 [details]
preprocessed file
Comment 2 Paolo Carlini 2010-10-05 16:46:41 UTC
I suppose you are referring to the sentences "leading zeros shall be permitted but shall not be required", right? Because they do *not* exist in the C(99) ISO Standard, which is the normative reference for C++98, in this area. In general, ISO 8601, in turn, is pretty strict about those formats.

Only C++0x references explicitly "the ISO/IEC 9945 function strptime" (ISO/IEC 9945 is the same as IEEE 1003), which is more flexible about leading zeros. Thus, C++0x work, in due course...
Comment 3 Paolo Carlini 2010-10-05 17:57:04 UTC
Can fix pretty quickly.
Comment 4 Paolo Carlini 2010-10-05 18:24:44 UTC
Actually, adding this sort of flexibility then hits http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461. Better dealing with this as part of a more general review of time_get for C++0x.
Comment 5 Jonathan Wakely 2017-07-13 10:04:22 UTC
*** Bug 71556 has been marked as a duplicate of this bug. ***
Comment 6 Jonathan Wakely 2017-07-13 10:05:10 UTC
Another testcase from PR 71556:

#include <iostream>
#include <sstream>
#include <locale>
#include <iomanip>
 
int main()
{
    std::tm t = {};
    std::istringstream ss("9");
    ss.imbue(std::locale("C.UTF-8"));
    ss >> std::get_time(&t, "%H");
    if (ss.fail()) {
        std::cout << "Parse failed\n";
    } else {
        std::cout << std::put_time(&t, "%c") << '\n';
    }
}
Comment 7 xyzdr4gon333 2017-07-14 14:32:19 UTC
Had this bug when trying "%m" formatter on input "7" input. Saw the comment from 7 years ago "Can fix pretty quickly." and let out a desperate laugh. Is C++11 dead?
Comment 8 Jonathan Wakely 2017-07-14 19:15:27 UTC
(In reply to xyzdragon from comment #7)
> Had this bug when trying "%m" formatter on input "7" input. Saw the comment
> from 7 years ago "Can fix pretty quickly." and let out a desperate laugh. Is
> C++11 dead?

The next comment, just half an hour later, pointed out it wasn't as simple as initially thought.
Comment 9 Jonathan Wakely 2019-03-20 19:42:07 UTC
*** Bug 89778 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Wakely 2019-03-20 19:43:01 UTC
Testcase from PR 89778:

#include <ctime>
#include <string>
#include <iomanip>
#include <sstream>
#include <iostream>

void printDate( const std::string &date_string ) {
  std::istringstream is( date_string );
  std::tm tm{};
  static const char *date_format( "%Y/%b/%d" );
  // d : parses the day of the month as a decimal number 
  //     (range [01,31]), leading zeroes permitted but not required 
  is >> std::get_time( &tm, date_format );
  char buf[ 20 ];
  std::strftime( buf, 20, date_format, &tm );
  std::cout << buf << '\n';
}

int main() {
  printDate( "2019/Apr/09" );
  printDate( "2019/Apr/9" );
  std::cout << '\n';
  printDate( "2017/Jan/02" );
  printDate( "2017/Jan/2" );
  std::cout << '\n';
  printDate( "2018/Dec/07" );
  printDate( "2018/Dec/7" );
}
Comment 11 Jonathan Wakely 2021-03-07 16:30:01 UTC
*** Bug 99439 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Jelinek 2021-12-10 16:20:20 UTC
Partly changed by the PR78714 r12-5898-gc82e492616e343b6d6db218d2b498267bac899de commit, but only for non-year format.