Sean Huang wrote:
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.
No, that's the point. It will be an incorrectly adjusted time....off by an hour.
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?
It's documented as not symmetric for the reasons above.
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.
That's exactly what I would suggest, although actually you can probably parse it into a time_duration. What are you going to do with the timezone offset once you get it? Do you need it for anything or do you just do a one time adjustment? Jeff