| Author |
time_get::get_date does not keep up with the standard
|
|
| Krzysztof Żelechowski 2005-03-10, 4:00 am |
| According to ANSI C++ standard, time_get::get_date should be able to read
back the output of time_put::put(..., 'x'). It is not the case for my locale
(Polish.852). The short date format is 2005.03.10; get_date is not able to
read it back. There are two reasons for this misdemeanour: 1. the period is
not recognized as the separator, it is easy to fix; 2. the order for a long
date is dmy and the order for a short date is ymd. It is hard to fix because
the ANSI standard does not support different orders for a short date and a
long date.
| |
| Igor Tandetnik 2005-03-10, 4:03 pm |
| "Krzysztof Zelechowski" <Krzysztofelechowski@discussions.microsoft.com>
wrote in message
news:6E8AEC7C-FF30-41B9-986E-75B33C4F2CB4@microsoft.com
> According to ANSI C++ standard, time_get::get_date should be able to
> read back the output of time_put::put(..., 'x'). It is not the case
> for my locale (Polish.852). The short date format is 2005.03.10;
> get_date is not able to read it back. There are two reasons for this
> misdemeanour: 1. the period is not recognized as the separator, it is
> easy to fix; 2. the order for a long date is dmy and the order for a
> short date is ymd. It is hard to fix because the ANSI standard does
> not support different orders for a short date and a long date.
Known problem with the standard
http://www.open-std.org/jtc1/sc22/w...active.html#461
Essentially, the requirement is deemed to be impossible to implement,
and it will be relaxed in the next version of the standard. Don't expect
it to work now or in the future.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Krzysztof Żelechowski 2005-03-28, 4:02 pm |
|
"Igor Tandetnik" wrote:
> "Krzysztof Zelechowski" <Krzysztofelechowski@discussions.microsoft.com>
> wrote in message
> news:6E8AEC7C-FF30-41B9-986E-75B33C4F2CB4@microsoft.com
>
> Known problem with the standard
>
> http://www.open-std.org/jtc1/sc22/w...active.html#461
>
> Essentially, the requirement is deemed to be impossible to implement,
> and it will be relaxed in the next version of the standard. Don't expect
> it to work now or in the future.
It is Mr Plauger's claim. Mr Plauger is *the* author of Microsoft STL
implementation. He did it wrong and is trying to find an excuse. No way.
| |
| Pete Becker 2005-03-28, 4:02 pm |
| Krzysztof Żelechowski wrote:
>
> It is Mr Plauger's claim. Mr Plauger is *the* author of Microsoft STL
> implementation. He did it wrong and is trying to find an excuse. No way.
Perhaps you overlooked the Library Working Group's comment from the last
meeting: "[Redmond: agreed that this is a real problem. The solution is
probably to match C99's parsing rules. Bill provided wording. ]"
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
| |
| Bo Persson 2005-03-28, 4:02 pm |
|
"Krzysztof Zelechowski" <Krzysztofelechowski@discussions.microsoft.com>
skrev i meddelandet
news:7FE9C25B-7D68-4843-A6F4-50C52140097C@microsoft.com...
>
>
> "Igor Tandetnik" wrote:
>
>
> It is Mr Plauger's claim. Mr Plauger is *the* author of Microsoft STL
> implementation. He did it wrong and is trying to find an excuse. No
> way.
But you just told us that it is hard to fix. :-)
The link shows us that Bill Plauger told the standard committee that a
year ago. And they agree!
He can't likely "fix" the implementation until the committee has agreed
on how to change it.
Bo Persson
| |
| Krzysztof Żelechowski 2005-03-29, 9:01 am |
|
"Bo Persson" wrote:
>
> "Krzysztof Zelechowski" <Krzysztofelechowski@discussions.microsoft.com>
> skrev i meddelandet
> news:7FE9C25B-7D68-4843-A6F4-50C52140097C@microsoft.com...
>
> But you just told us that it is hard to fix. :-)
>
There is a difference between "hard" and "impossible", especially for
someone who can #include CRT's internal headers. And time_put and time_get
should be mutually reverse in parallel to locale-dependent functions
(strftime) and (strptime) under Linux so it is not a good idea to restrict
time_get to C language. It voids the idea of STL locale support.
Chris
|
|
|
|