Boost C++ Libraries: Ticket #7868: chrono_io parses time incorrectly (1.53 and 1.52)

status changed

viboes — Fri, 18 Jan 2013 20:50:59 GMT

status new → assigned

Hi,

I think that I have found the fix. Please could you try adding in boost/chrono/io/time_point_io.hpp the following missed initialization.

            tm.tm_sec=0;

before

#if defined BOOST_CHRONO_USES_INTERNAL_TIME_GET
            const detail::time_get<CharT>& dtg(tg);
            dtg.get(is, 0, is, err, &tm, pb, pe);
#else
            tg.get(is, 0, is, err, &tm, pb, pe);
#endif

milestone changed

viboes — Fri, 18 Jan 2013 21:11:57 GMT

milestone To Be Determined → Boost 1.53.0

Here it is a patch to fix it.

svn diff boost/chrono
Index: boost/chrono/config.hpp
===================================================================
--- boost/chrono/config.hpp	(revision 82527)
+++ boost/chrono/config.hpp	(working copy)
@@ -28,7 +28,7 @@
 #if ! defined BOOST_CHRONO_PROVIDES_DATE_IO_FOR_SYSTEM_CLOCK_TIME_POINT \
     && ! defined BOOST_CHRONO_DONT_PROVIDE_DATE_IO_FOR_SYSTEM_CLOCK_TIME_POINT
-# define BOOST_CHRONO_DONT_PROVIDE_DATE_IO_FOR_SYSTEM_CLOCK_TIME_POINT
+# define BOOST_CHRONO_PROVIDES_DATE_IO_FOR_SYSTEM_CLOCK_TIME_POINT
 #endif
Index: boost/chrono/io/time_point_io.hpp
===================================================================
--- boost/chrono/io/time_point_io.hpp	(revision 82527)
+++ boost/chrono/io/time_point_io.hpp	(working copy)
@@ -936,6 +936,7 @@
             { '%', 'Y', '-', '%', 'm', '-', '%', 'd', ' ', '%', 'H', ':', '%', 'M', ':' };
             pb = pattern;
             pe = pb + sizeof (pattern) / sizeof(CharT);
+            tm.tm_sec=0;
 #if defined BOOST_CHRONO_USES_INTERNAL_TIME_GET
             const detail::time_get<CharT>& dtg(tg);
             dtg.get(is, 0, is, err, &tm, pb, pe);

viboes — Fri, 18 Jan 2013 22:03:04 GMT

Committed in trunk revision [82541].

viboes — Sun, 20 Jan 2013 19:42:51 GMT

There is yet an issue with gmtime on Windows when the time_t parameter is < 0. I have added an internal implementation for this function in Changeset [82562].

Then I have made that system clock counts periods "since January 1, 1970, UTC" And activated the use of the internal gmtime function on windows in Changeset [82563].

This should fix the issue.

status changed; resolution set

viboes — Sun, 27 Jan 2013 12:34:38 GMT

status assigned → closed
resolution → fixed

Changeset [82612] Chrono: merge [82562][82663].

status, version, milestone changed; resolution deleted

lundberj@… — Sun, 30 Jun 2013 23:00:30 GMT

status closed → reopened
version Boost 1.52.0 → Boost 1.54.0
resolution fixed
milestone Boost 1.53.0 → Boost 1.54.0

I'm sorry to say that the bug still remains with beta 1.54 (beta0). Specifically the second part of the test code I posted, where the final seconds are always the same, and do not reflect the real time.

Other formats, such as "%Y-%m- %S %d %H:%M" seems to quietly fail.

In addition, documentation for this seems to be missing (at least I could not find it): What are the allowed markers (%S and friends) and what syntax must a format string have? (such as this one for date_time_io: http://www.boost.org/doc/libs/1_53_0/doc/html/date_time/date_time_io.html )

As and example, I wanted to find out the syntax for manually defining the default format, such as: 2013-06-30 20:01:15.584512 +0000 but I could not find out how to specify the fractional seconds or the time zone mark. Those are things a user should be able to find out.

milestone changed

viboes — Sun, 07 Jul 2013 11:28:32 GMT

milestone Boost 1.54.0 → Boost 1.55.0

You are right. The ticket is not completely fixed. There was some comments in the time_point parsing input. The following patch should solve this particular issue, but I gues that I would need to complete the unit tets

Index: io/time_point_io.hpp
===================================================================
--- io/time_point_io.hpp	(revision 84889)
+++ io/time_point_io.hpp	(working copy)
@@ -255,9 +255,9 @@
 //                b = that_.get(b, e, iob, err, tm, fm, fm + sizeof(fm)/sizeof(fm[0]));
 //                }
 //                break;
-//            case 'S':
-//              that_.get_second(tm->tm_sec, b, e, err, ct);
-//                break;
+            case 'S':
+              get_second(tm->tm_sec, b, e, err, ct);
+                break;
 //            case 'T':
 //                {
 //                const char_type fm[] = {'%', 'H', ':', '%', 'M', ':', '%', 'S'};

viboes — Sun, 07 Jul 2013 11:38:21 GMT

Committed revision [84967]. Committed revision [84973].

status changed; resolution set

viboes — Fri, 13 Sep 2013 19:31:49 GMT

status reopened → closed
resolution → fixed

Changeset [85610]

Sun, 15 Sep 2013 08:40:31 GMT

Great! It also passes my tests.

A while back I reported compiler warnings on initializing the tm struct. The preferred solution at other places (https://svn.boost.org/trac/boost/changeset/80797/branches/release/boost/date_time/date_facet.hpp) is

std::tm dtm; std::memset(&dtm, 0, sizeof(dtm));

That also initialize any allowed but unspecified members in addition to the ones required by the standard.

I still miss the fractional seconds part. Perhaps this is a feature-request, but that would make it possible to make full use of these facilities in a much wider range of applications. It would also allow to manually specify variants of the default format which does have fractional seconds, "1970-01-01 00:02:46.666667 +0000".

viboes — Sun, 15 Sep 2013 16:21:10 GMT

Replying to Johan Lundberg <lundberj@…>:

Great! It also passes my tests.

A while back I reported compiler warnings on initializing the tm struct. The preferred solution at other places (https://svn.boost.org/trac/boost/changeset/80797/branches/release/boost/date_time/date_facet.hpp) is

std::tm dtm; std::memset(&dtm, 0, sizeof(dtm));

That also initialize any allowed but unspecified members in addition to the ones required by the standard.

Please create a new bug ticket for that. I will fix it.

I still miss the fractional seconds part. Perhaps this is a feature-request, but that would make it possible to make full use of these facilities in a much wider range of applications. It would also allow to manually specify variants of the default format which does have fractional seconds, "1970-01-01 00:02:46.666667 +0000".

Please create a new feature request for any changes you need.