Boost logo

Boost Users :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-10-01 14:16:36


Sean Huang wrote:
> ----- Original Message -----
> From: "Jeff Garland" <jeff_at_[hidden]>
> To: <boost-users_at_[hidden]>
> Sent: Sunday, October 01, 2006 12:47 PM
> Subject: Re: [Boost-users] [date-time]time zone input
>
>
>> No plans at this point. There's a basic problem in that %q/%Q doesn't
>> have
>> enough information to construct a timezone object that has DST rules and
>> such
>> so the only thing the library could do is assume the TZ doesn't have DST.
>> Of
>> course, that mostly a poor assumption so it could lead to nasty errors...
>>
> Jeff,
>
> Thanks for the reply. There are standards that specificy date-time in
> formats similar to:
>
> YYYYMMDDHHMMSS.FFFFFF&ZZZZ
>
> Without input support for ZZZZ, we have to implement messy workarounds if we
> want to continue using boost::date_time.

Ok. Of course, given the speed of fixes/boost releases you'll probably have
some sort of 'workaround'. Hopefully we can make it bit cleaner :-)

> I'm not an expert on date-time so please bear with my naive questions.

No problem, I never assume to know everything in this domain.

> It is not obvious to me why a simple time zone with only time-offset could
> lead to nasty errors. Isn't the format above enough to convert a time to UTC
> unambiguously?

Ok, let me go a bit deeper on the issues here. Basically when do something
like this:

  std::stringstream ss;
  ss.str("2004-Feb-29 12:34:56.000789 EDT-05EDT,M4.1.0,M10.5.0");
  local_date_time ldt(not_a_date_time);
  ss >> ldt;

you are getting 2 objects: the time point and the time zone specification. In
this case we have a posix tz specification that allows for calculation based
on this time point to work correctly for all times in the future. So if you do:

  ldt += months(5);

which happens to convert your time into a period of daylight savings. But,
all is well because the attached timezone object has enough information to
adjust the time point as needed. If something like this were allowed:

  ss.str("2004-Feb-29 12:34:56.000789-05");
  local_date_time ldt(not_a_date_time);
  ss >> ldt;

then the constructed timezone would have no information about the true nature
of the timezone. So now if you say

  ldt += months(5);

the only possible assumption the library can make is that there is no daylight
savings -- it is only aware of the UTC offset. This sort of assumption
doesn't work for a good percentage of the world, so it's a dangerous
assumption for the library to make. Worse than that, it's almost impossible
to see the error unless you are very careful with the test data you run - so
it might work for 6 months and then boom. In your particular use cases it
might be perfectly fine...don't know you'd have to give more context.

There's lots of ways you can workaround this (write a custom tz parser -- not
as hard as it sounds, a custom timezone type, etc)....so maybe you can give me
a bit more context on your app and I can point you to a 'less messy' workaround.

Jeff


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net