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

Sean Huang wrote:

----- Original Message ----- From: "Jeff Garland" To: 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