Re: [Boost-users] [date_time]time zone input

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