On Sat, May 24, 2008 at 7:12 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> Mark Phippard wrote:
>>
>> Yesterday we created a new class called LogDate that goes with some
>> recent API catch up that was committed to 1.5.x I created a test case
>> for this class and it was backported.
>>
>> One of the things the test does is parse a sample of a Subversion date
>> into the time in microseconds. The way I wrote the test is I ran it
>> once so that it would fail and then copied the right value into the
>> test so that it would work. I think that something about my test
>> might make it only work in the Eastern Time Zone. Since I am in the
>> Eastern time zone it makes it hard for me to test.
>>
>> The reason I think this is that I just had my Windows PC set to GMT
>> and ran the tests and it failed. When I put it back to EDT then it
>> works. This could also be some weird Windows bug. I just wanted to
>> give a heads up. If that test fails for you, then this might be the
>> reason why.
>>
>> The reason I set my PC to GMT is just so that I get the right
>> date/time stamps on our files when I unzipped the RC6 distribution. I
>> had forgotten to set it back before I built and ran the tests.
>>
>> Like I said, there might not be a problem here. That said, in this class:
>>
>>
>> http://svn.collab.net/repos/svn/trunk/subversion/bindings/javahl/src/org/tigris/subversion/javahl/LogDate.java
>>
>> When it creates a Calendar object, I wonder if it should get it
>> specifically with the GMT timezone?
>
> Why not ignore this problem and put the string to time conversion back in
> the C code? I think this is a better idea then using code that only a few
> developers know in the Java layer. I do Java/Scala development now and I
> never use the conversion class that LogDate does. The C conversion iss more
> well known by all the developers. It's also probably faster.
I am sure the Java classes are just as reliable as the C classes.
Since the revprops are coming in a Map, it makes sense that they are
consistently all the same type of object, in which case it needs to be
a String. I also agree with Hyrum that it makes sense to do as much
logic in Java as we can.
I think there are two possibilities here:
1) If the Subversion date is always in your local time zone, then the
current LogDate code is probably correct and we should just get rid of
the check in the test.
2) If the Subversion date is always for GMT, then the code in LogDate
is probably wrong and the test will also need to be adjusted for the
right value.
What I did was open one of my revprop files and cut & paste the date
from it into the test. I then ran it and let if fail and observed the
expected value. Then copied that into the test.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-25 01:16:42 CEST