Jeff,
Thanks for the prompt reply. More questions are below inline. :-)
----- Original Message -----
From: "Jeff Garland"
Ok, let me go a bit deeper on the issues here. Basically when do something like this:
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. Thanks for the detailed explanation. I have not done much work on date/time so I 'll take your word for it. On the other hand, I'm still not totally convinced this is such a bad assumption to make (or should we make it a convention :-)). If people do ldt+= months(5), ldt still has the right time. It only causes confusion if ldt is displayed without a time-zone offset. Also, because %q/Q is supported for output (for example, your ISO format example in the documentation), shouldn't there be corresponing input support for symmetry?
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. That would be great. What we are trying to do is to convert DICOM DT (Date time) element to boost::date_time and it is in the format shown below: YYYYMMDDHHMMSS.FFFFFF&ZZZZ One way I can think of is treat the string as posix time and parse the time-zone offset part ourselves. It sounds like there are better ways to accomplish this. I would appreciate it very much if you could point me to the right direction.
Thanks, Sean