cpp-netlib-devel

[cpp-netlib-devel] rfc2822 parsers

[Christian H. <chh...@gm...>]

Hi there, I have been testing the parsers using their test cases. The
date tests fail in the current configuration. The solution I think is
simple. In one case for example the the parser is required to generate
this following string:

1982-06-12 00:00:00

which it doesn't. The input string is

12 jUN 1982

The output is just

1982-06-12

So, that means the trailing 00:00:00 is missing.

Does anybody know if that is problem?

Christian

Re: [cpp-netlib-devel] rfc2822 parsers

[Dean M. B. <mik...@gm...>]

On 5/18/07, Christian Henning <chh...@gm...> wrote:
[snip]
>
> Does anybody know if that is problem?
>

I haven't the chance to check out Peter's library yet, but a question
I have would be whether we're using/converting the strings to a
Boost.Date_time object?

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] rfc2822 parsers

[Peter S. <si...@cr...>]

Hi Christian,

I cannot know for sure, but I suspect that limitations in
strftime() cause this problem. The test case uses that function
to format the parsed 'tm' structure, and apparently something is
going wrong on that end. The following patch should remedy the
issue:

  http://git.cryp.to/?p=librfc2822;a=commitdiff;h=e84b5a6d386bc687e2586276d8997eb73dce207f

Best regards,
Peter

Re: [cpp-netlib-devel] rfc2822 parsers

[Peter S. <si...@cr...>]

Hi Dean,

personally, I would prefer sticking to std::tm as the result type
of choice for the date parser. I wouldn't want to introduce a
dependency on Boost.Date_time unless I have to. Manipulating a
std::tm timestamp with the date_time library is simple enough
from the on.

Just my 0.02 Euros,
Peter

Re: [cpp-netlib-devel] rfc2822 parsers

[Dean M. B. <mik...@gm...>]

On 18 May 2007 21:16:37 +0200, Peter Simons <si...@cr...> wrote:
> Hi Dean,
>
> personally, I would prefer sticking to std::tm as the result type
> of choice for the date parser. I wouldn't want to introduce a
> dependency on Boost.Date_time unless I have to. Manipulating a
> std::tm timestamp with the date_time library is simple enough
> from the on.
>

Agreed. :) I was just wondering aloud. :D

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] rfc2822 parsers

[Christian H. <chh...@gm...>]

I can second that. If you only need to parse some string to generate
std::tm structure than I would think we don't need boost::date_time.

Thanks Peter, for your fix. It's not quite the working though ;-) The
output now is:

1982-06-12 01:00:00

Seems to me that the time value is off by an hour. When looking inside
the std::tm structure the tm_hour member is 1.

Christian


On 18 May 2007 21:16:37 +0200, Peter Simons <si...@cr...> wrote:
> Hi Dean,
>
> personally, I would prefer sticking to std::tm as the result type
> of choice for the date parser. I wouldn't want to introduce a
> dependency on Boost.Date_time unless I have to. Manipulating a
> std::tm timestamp with the date_time library is simple enough
> from the on.
>
> Just my 0.02 Euros,
> Peter
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] rfc2822 parsers

[Peter S. <si...@cr...>]

Hi Christian,

 > The output now is: 1982-06-12 01:00:00
 >
 > Seems to me that the time value is off by an hour.

Well, I doubt this phenomenon indicates a bug in the parsers.
This feels more like an OS level problem; like the OS applies
some sort of timezone conversion in mktime() -- a function the
test program uses. It's possible that adding a call to tzset() at
the beginning of the test case improves matters:

--- a/test-date.cpp
+++ b/test-date.cpp
@@ -103,6 +103,8 @@ struct runner

 BOOST_AUTO_TEST_CASE( test_rfc2822_date_parser )
 {
+  tzset();
+
   // Init timezone.

   {

If that doesn't help, I'm fresh out of ideas. I haven't observed
that particular problem before.

Best regards,
Peter

Re: [cpp-netlib-devel] rfc2822 parsers

[Christian H. <chh...@gm...>]

For whatever reasons my offset to gmt is 4 hours. But it should be 5.
Don't know why this is. ;-(

On 18 May 2007 21:57:05 +0200, Peter Simons <si...@cr...> wrote:
> Hi Christian,
>
>  > The output now is: 1982-06-12 01:00:00
>  >
>  > Seems to me that the time value is off by an hour.
>
> Well, I doubt this phenomenon indicates a bug in the parsers.
> This feels more like an OS level problem; like the OS applies
> some sort of timezone conversion in mktime() -- a function the
> test program uses. It's possible that adding a call to tzset() at
> the beginning of the test case improves matters:
>
> --- a/test-date.cpp
> +++ b/test-date.cpp
> @@ -103,6 +103,8 @@ struct runner
>
>  BOOST_AUTO_TEST_CASE( test_rfc2822_date_parser )
>  {
> +  tzset();
> +
>    // Init timezone.
>
>    {
>
> If that doesn't help, I'm fresh out of ideas. I haven't observed
> that particular problem before.
>
> Best regards,
> Peter
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] rfc2822 parsers

[Dean M. B. <mik...@gm...>]

On 5/18/07, Christian Henning <chh...@gm...> wrote:
> For whatever reasons my offset to gmt is 4 hours. But it should be 5.
> Don't know why this is. ;-(
>

Maybe has something to do with the DST stuff?

(Not too familiar with DST and how that works/breaks, I live in GMT +8 :D )
-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459