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

From: Sean Huang (huangsean_at_[hidden])
Date: 2006-10-01 15:19:24

Jeff,
Thanks for the prompt reply. More questions are below inline. :-)

----- Original Message ----- 
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Sunday, October 01, 2006 2:16 PM
Subject: Re: [Boost-users] [date_time]time zone input

> 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