[date_time] Pinging Jeff Garland re new Borland regression
Hallo, Jeff. Just in case you didn't notice this: http://article.gmane.org/gmane.comp.lib.boost.testing/4236 I just realized that I hid the fact that it is related with the date_time library rather well. Cheers, Nicola Musatti
Nicola Musatti wrote:
Hallo, Jeff. Just in case you didn't notice this: http://article.gmane.org/gmane.comp.lib.boost.testing/4236
I didn't...sorry I was on travel.
I just realized that I hid the fact that it is related with the date_time library rather well.
Ok, I've looked at it. It clearly looks like a DST related problem. I can't tell if it's a machine configuration problem or a library problem...I just know it's something boost date-time can't really fix. Essentially the problem is that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime. So unless the owner of the machine can diagnose why this has started I guess we should mark this one as expected. Jeff
Jeff Garland wrote: [...]
Ok, I've looked at it. It clearly looks like a DST related problem. I can't tell if it's a machine configuration problem or a library problem...I just know it's something boost date-time can't really fix. Essentially the problem is that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime. So unless the owner of the machine can diagnose why this has started I guess we should mark this one as expected.
Meanwhile I found that I have the same problem, with both 5.6.4 and 5.8.2 . I would guess it is a matter of locale not being properly set or detected. Does it sound reasonable? Anyway, I personaly have no problem with it being marked expected. Cheers, Nicola Musatti
Jeff Garland wrote:
Ok, I've looked at it. It clearly looks like a DST related problem. I can't tell if it's a machine configuration problem or a library problem...I just know it's something boost date-time can't really fix. Essentially the problem is that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime. So unless the owner of the machine can diagnose why this has started I guess we should mark this one as expected.
I can reproduce this here: the test fails with Borland 5.8.2 and 5.6.4 but passes with msvc-8, intel-9.1 and mingw32. So it's a runtime library issue, not a system one by the looks of it. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Jeff Garland wrote:
Ok, I've looked at it. It clearly looks like a DST related problem. I can't tell if it's a machine configuration problem or a library problem...I just know it's something boost date-time can't really fix. Essentially the problem is that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime. So unless the owner of the machine can diagnose why this has started I guess we should mark this one as expected.
I can reproduce this here: the test fails with Borland 5.8.2 and 5.6.4 but passes with msvc-8, intel-9.1 and mingw32. So it's a runtime library issue, not a system one by the looks of it.
That's a known bug in the Borland library. Well, known to some people, anyway: I was told about that bug a few months ago in an unrelated discussion. I don't remember whether there was a workaround. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Ok, I've looked at it. It clearly looks like a DST related problem. I can't tell if it's a machine configuration problem or a library problem...I just know it's something boost date-time can't really fix. Essentially the problem is that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime. So unless the owner of the machine can diagnose why this has started I guess we should mark this one as expected. I can reproduce this here: the test fails with Borland 5.8.2 and 5.6.4 but
Jeff Garland wrote: passes with msvc-8, intel-9.1 and mingw32. So it's a runtime library issue, not a system one by the looks of it.
That's a known bug in the Borland library. Well, known to some people, anyway: I was told about that bug a few months ago in an unrelated discussion. I don't remember whether there was a workaround.
I've marked this as expected now :-( Jeff
participants (4)
-
Anthony Williams -
Jeff Garland -
John Maddock -
Nicola Musatti