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

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

Sean Huang wrote:

----- Original Message ----- From: "Jeff Garland" To: Sent: Sunday, October 01, 2006 8:03 PM Subject: Re: [Boost-users] [date_time]time zone input

...

...

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. Can you elaborate on this a bit more?

See below.

I just use it to do a one-time adjustment. I agree with you that the aforemented format does not fully specify a time zone (I guess I used the wrong subject in the first place. :-)). DICOM only uses the ZZZZ as the offset from UTC and that's how we plan to use ZZZZ. We'll convert it to UTC time as soon as it is parsed.

Ok, easy as pie. We'll set the time_duration_format format, stream it in and convert to utc: try { //setup your input facet time_input_facet *facet = new time_input_facet(); facet->set_iso_format(); facet->time_duration_format("%H%M"); // just get a tz parts some_stream_instance.imbue(std::locale(std::locale::classic(), facet)); //stream the parts in ptime t; time_duration td(0,0,0); //get the time part t >> some_stream_instance; //now get the utc offset td >> some_stream_instance; t += td; //convert time to UTC } catch(std::exception& e) I didn't compile or run this...you'll what some error handling...but I'm 99% sure it will do what you want :-) Jeff

Sean Huang wrote:

----- Original Message ----- From: "Jeff Garland" To: Sent: Sunday, October 01, 2006 10:31 PM Subject: Re: [Boost-users] [date_time]time zone input

...

Ok, easy as pie. We'll set the time_duration_format format, stream it in and convert to utc:

try { //setup your input facet time_input_facet *facet = new time_input_facet(); facet->set_iso_format(); facet->time_duration_format("%H%M"); // just get a tz parts some_stream_instance.imbue(std::locale(std::locale::classic(), facet));

//stream the parts in ptime t; time_duration td(0,0,0);

//get the time part t >> some_stream_instance; //now get the utc offset td >> some_stream_instance; t += td; //convert time to UTC } catch(std::exception& e)

I didn't compile or run this...you'll what some error handling...but I'm 99% sure it will do what you want :-)

I actually thought about this but encountered a problem with the sign part (for example, +05:00). According to the documentation, "%+" and "%-" only work for output. I just tried again and got an exception (with 1.33). Maybe I am missing something here...

Oh crud...that's not good. That needs to be fixed for sure...

In any rate, it is easy to parse the offset part ourselves.

Yep.

Again, thank you very much for your help!

Sure thing :-)

By the way, shouldn't it be t-=td?

No, b/c I was expecting the sign to be pulled out by the streaming operator. So if it is -0700 and you add it will go back from UTC. Similarly if it's +0700 it also does the right thing. Basically, you don't want to change the sign by subtracting. So in your parsing code you'll have to pull out the sign and then subtract or add as appropriate. Jeff

Sean Huang wrote:

By the way, have you taken a look at this regression issue on WinXP-64:

http://tinyurl.com/g6nbn

Looks like it is unique to 64-bit windows.

Let me know if you need any help diagnosing the problem.

I know what the problem is...the machine is too fast or the clock is poor. Basically, there is a loop that's supposed to waste some time to make sure the next time measured from the clock is greater than the last time. The whole point of the test is to validate that the clock api in fact works as advertised. In the case of your machine the 'last' and 'next measurements come out equal instead of less...which leads me to conclude that the loop finishes before the clock updates. So basically this is a non-failure. I suppose I could bump up the loop count...or you could get a slower machine ;-) Jeff

Sean Huang wrote:

----- Original Message ----- From: "Jeff Garland" To: Sent: Sunday, October 01, 2006 11:35 PM Subject: Re: [Boost-users] 64bit windows regression failure (was [date_time]time zone input)

...

So basically this is a non-failure. I suppose I could bump up the loop count...or you could get a slower machine ;-)

I see. In light of this, isn't it better to change the test from "<" to "<="?

Well I've considered that in the past when this has come up, but always decided against it on the thought that I would rather see the error if the clock didn't actually increment correctly. So I would be worried if the sequence was something like: 0 0 0 0 0 10 If you have a minute, change the for loop in test/posix_time/testmicrosec_time_clock.cpp for (int j=0; j<100000; j++) { // some systems loop too fast so "last is less" tests fail maybe make 100000 into 500000 and see if the test passes. Jeff