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.
Blair
---------------------------------------------------------------------
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:12:31 CEST