This project has moved and is read-only. For the latest updates, please go here.

KmlFormatterTest unit test fails


In the DateTime unit test it first tries on {10/11/2012
09:08:07} local time (I am in Jerusalem Standard Time at the moment), and the ValueConverter.TryGetValue returns a value of {10/11/2012
07:08:07} UTC. This is the same actual time, but of course the assertion fails.

And another point - I think this unit test should be split to at least 3 tests - one for each Kind. I had a failure, and I had to debug it manually in order to see which of the 3 kinds fails.


ATGardner wrote Oct 7, 2012 at 7:50 AM

I updated from svn, and still have the same failures.
The problem is still that the second assert in the TestDateTime method compares between

{10/11/2012 09:08:07} [date.Kind Local System.DateTimeKind]
{10/11/2012 07:08:07} [((DateTime)parsed).Kind Utc System.DateTimeKind]

And they are not equal.
The ValueConverter always returns Dates in UTC.

samcragg wrote Oct 7, 2012 at 8:39 AM

I believe the issue should now have been solved in the latest release.

I've also separated the test into three methods so if one does fail it will be easier to find the problem.

** Closed by samcragg 06/10/2012 14:46

samcragg wrote Oct 7, 2012 at 8:39 AM

samcragg wrote Oct 7, 2012 at 8:44 AM

I can't get the unit tests to fail at the moment, which is making it hard to know if the issue has been fixed!

I think I should be able to fix it by changing the comparision to compare the parsed value with date.ToUniversalTime(), but as I can't get the test to fail I want to verify that this will fix it.

Can you let me know what culture settings you are running with (i.e. what does Thread.CurrentThread.CurrentCulture.DisplayName return) so I can try running the tests under that?

ATGardner wrote Oct 8, 2012 at 9:55 PM

Maybe you can try by just changing your computer's timezone to Jerusalem Standard Time, that way you'll get the +2 that I am having here at the moment.

If the second assert would be between date.ToUniversalTime() and ((DateTime)parsed).ToUniversalTime() it will pass even when date is Local Time. But this will only prove that parsed is the same "Time Instance" as date, but they will still be of different Kinds.

Here are the current values when pausing in debug -
date {10/11/2012 09:08:07} System.DateTime
date.Kind Local System.DateTimeKind
date.Ticks 634881352870000000 long
((DateTime)parsed) {10/11/2012 07:08:07} System.DateTime
((DateTime)parsed).Kind Utc System.DateTimeKind
((DateTime)parsed).Ticks 634881280870000000 long
date.ToUniversalTime() {10/11/2012 07:08:07} System.DateTime
date.ToUniversalTime().Kind Utc System.DateTimeKind
date.ToUniversalTime().Ticks 634881280870000000 long

Anyway, my DisplayName is
Thread.CurrentThread.CurrentCulture.DisplayName "Hebrew (Israel)"

Hope it helps.

wrote Feb 22, 2013 at 12:00 AM

jcteague wrote Feb 15, 2016 at 10:31 PM

I just pulled the source from svn and I'm having the same issues. I'm in CST timezone.

I actually have 5 tests failing. PointTest.TestParseAltitudeMode & Engine.KmzFileTest