PrettyDate calculation is incorrect

[mightymuke]

The dateTime being processed in is UTC (for Jenkins at least). This is then compared with the current time in the current timezone for the pretty conversion.

This is a trivial fix for Jenkins - ie in PrettyDateHelper.cs change

        public static string PrettyDate(this DateTime dateTime)
        {
            return PrettyDate(dateTime, DateTime.Now);
        }

to

        public static string PrettyDate(this DateTime dateTime)
        {
            return PrettyDate(dateTime, DateTime.UtcNow);
        }

But is this the correct solution for all CI servers?

[lprichar]

So I'm hoping you can help me out sir. I tried to reproduce this bug by modifying the MockCi Server to return date/times in UTC, however the pretty date calculations still came out correct.

That result was actually consistent with how I thought it should work since it should always use the BuildStatusDto.LocalStartTime rather than the BuildStatusDto.StartTime (server time) for those calculations. In other words, it shouldn't matter what date the server returns, it should always use it's local version of the time in a local timezone. As long as everything is internally consistent there shouldn't be any timezone problems possible.

But you're experience is clearly counter to that theory, so I must be missing something. Maybe an odd localization thing specific to Kiwi's ;). Would you be willing to put a breakpoint on ViewBuildBase.cs:378 (startTimeLabel.Text = LocalStartTime.PrettyDate()) and see if LocalStartTime is in fact somehow being set to a UTC date? If so could you help me track it back to see how it got set? Any help would be greatly appreciated.

Sincerely,
Lee

[mightymuke]

Thank you so much for taking the time to look at this issue! Its such an awesome application and I feel honoured to be able to help in any way I can.

I am certainly very willing to apply the aforementioned breakpoint, but unfortunately it must await until Monday arrives as I currently do not have access to the CI Server. However as we Kiwi's are so far ahead of the USA, thankfully you shouldn't have to wait long.

Sincerely,
MM

(You started it...)

[mightymuke]

Sorry I didn't do it today cos I'm a slacker, but here's proof that I'm not lying: http://screencast.com/t/8D3xcBj5kc3Q

[lprichar]

Oh! You mean the "7 minutes ago" on the main form part is correct, but the date/time listed in full screen mode is incorrect?

[lprichar]

Confirmed it's not working correctly in full screen mode, don't worry about the breakpoint I mentioned earlier and thanks for the screencast! I'll get this fixed shortly, although it may yet be a while since us yanks are so far behind y'all. :)

[mightymuke]

That's fine - I'm used to it ;)

I'll also double check the date on the main display. I'm sure its all ok (as seen in the screencast), but I have a feeling there was something odd with that too.

[mightymuke]

You can see all the source dates are incorrect:

They are generally rendered correctly in the UI for any dates less than 35 days old because of the PrettyDateHelper. However I still think there is an argument to store dates in GMT / UTC, and display them in the appropriate timezone.

[lprichar]

Now I'm really confused. The screenshot you just showed has times in it. But if those dates are older than 35 days they should be coming from PrettyDateHelper:24 which is dateTime.ToString("d"). The "d" format specifier should never return times.

I'm not sure exactly which culture you're in, but I checked with this fancy little app:

http://archive.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=clrsamples&DownloadId=14861

and all of the "en" ones and the invariant culture all return a month, a day and a year only. Furthermore some of the dates in your screenshot are under 35 days ago, so they should have been formatted pretty.

So I'm confused about all that. But I did fix the full screen date bug so unless you strongly object I'm going to close this issue.

[mightymuke]

Yeah, I changed it to a "g" to demonstrate it. The date is (was) wrong depending on the time (day early if build was before lunch). I'll test out the fix on Monday.