Mark Phippard wrote:
> 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.
I'm not debating that. But there's more code to check out the behavior for.
> 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.
Not when it adds to the overhead of understanding what the code does.
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:21:45 CEST