Software Warlock

This sounds like an April fools day prank, but it actually isn’t (it’s an every-day prank) as I’ve been seeing it for a while. When you access MSDN pages via Chrome, the MSDN logo in the upper-left get’s replaced with some sort of picture that looks like a container with money in it:

I’ve tried with a couple other web browsers (IE, FF) and it all appears normal. The only other explanation is that Microsoft is detecting the browser on the back-end, but that doesn’t seem likely. Note that this isn’t some sort of Chrome CSS hack, as the image appears incorrectly even if you’re browsing directly to the image URL.

I just got back from a talk about Groovy metaprogramming at the Twin Cities Programming Languages User Group (great talk) and I was impressed to see how similar some of the ideas were to those in Objective-C. This was my first exposure to Groovy, and I like a lot of its core ideas in this area because like Objective-C, it’s has its roots in Smalltalk. The one thing I like better from Smalltalk/Objective-C is the core idea of a message as opposed to a method call. Groovy allows you intercept a method call and do custom behavior, and that thought doesn’t sit quite as well as incepting a message. It’s just a terminology thing, probably because of the good ‘ol days in C. More on this stuff as I get additional exposure.

A while back I was debugging some code that needed to query a database for reservations that happened within a certain date range. For example, I’d want all reservations for a week, and would search for reservations that started anywhere between Sunday at 12:00 a.m. to Saturday at 11:59:59 p.m. The code that computed the date range was in .NET, so to get the end date I would do startDate.AddDays(7).AddTicks(-1). Assuming the start date was the first day of the week, this would be as inclusive as possible by going forward to the following Sunday and then pulling back into Saturday by the smallest increment offered by .NET. This should mean that any reservation stating in Saturday would be included, but even those at 12:00 a.m. on the following Sunday would not. Instead, the query kept returning those reservations on the following Sunday at 12:00 a.m.

The problem turned out to be the precision offered by SQL Server’s representation of dates and times. SQL Server offers two types for working with dates & times: DATETIME and SMALLDATETIME (TIMESTAMP is also offered, but that’s not not actually used to store values but rather track when a row has been modified). DATETIME stores the number of 1/300 unit increments after midnight, meaning it has precision to 3.33 milliseconds. SMALLDATETIME is stored as two two-byte integers. The date component is the number of days after January 1, 1900 (meaning dates before this date cannot be represented) and the time component is the number of minutes since midnight. With this representation seconds aren’t actually represented at all, so for input dates with seconds less than or equal to 29.998 the time is rounded down and for those greater than or equal to 29.999 the time is rounded up tot he next minute.

As it turned out, my problem query was dealing with a SMALLDATETIME and I had to back of the precision of the .NET code to accommodate. More information about SQL Server dates & times is available here.

As I’ve mentioned previously, I spend a lot of time dealing with date/time localization issues. As such, this entry from the Daily WTF was extremely applicable to me.

I could post some stuff that would make this code look like a good idea, but I’m pretty sure that would be frowned upon.

I’ve been sitting on this one for a while, but a little quirk in the implementation of DateTime.Parse method is that the date separator and time separator cannot be the same thing. It’s documented at this MSDN article:
http://msdn2.microsoft.com/en-us/library/1k1skd40.aspx

Despite the fact that it’s a “feature” it can be a gotcha if you ever run into it.

using System;
using System.Text;
using System.Globalization;

namespace DateTimeSeparatorSameThingDemo
{
	class Program
	{
		static void Main(string[] args)
		{
			DateTimeFormatInfo invariantDTFI = CultureInfo.InvariantCulture.DateTimeFormat;
			DateTimeFormatInfo localizedDTFI = CultureInfo.CurrentUICulture.DateTimeFormat;

			Console.WriteLine("Invariant Date Separator: " + invariantDTFI.DateSeparator);
			Console.WriteLine("Invariant Time Separator: " + invariantDTFI.TimeSeparator);

			Console.WriteLine();

			Console.WriteLine("Localized Date Separator: " + localizedDTFI.DateSeparator);
			Console.WriteLine("Localized Time Separator: " + localizedDTFI.TimeSeparator);

			Console.WriteLine();

			Console.WriteLine("Using Default Culture Settings To Localized: ");
			Console.WriteLine(DateTime.Now.ToString());
			Console.WriteLine();

			// Uncomment the following line to throw exception when DateSeparator is the
			// same as the time separator, as configured in the windows regional settings
			//Console.WriteLine(DateTime.Parse(DateTime.Now.ToString()).ToString());

			Console.WriteLine();

			// This is the correct way to send a date/time to a string and re-parse it.
			string tmpDateTime = DateTime.Now.ToString(invariantDTFI);
			DateTime parsedDateTime = DateTime.Parse(tmpDateTime, invariantDTFI);

			// Using ToString without a DateTimeFormatInfo will display the date time
			// in the localized format, but it's better to be explicit
			Console.WriteLine("Displaying the parsed DateTime as expected by the user:");
			Console.WriteLine(parsedDateTime.ToString(localizedDTFI));

			// Wait for user to view the results
			Console.ReadLine();
		}
	}
}

You may think you have an infinitely recurring appointment, but you’re wrong. It turns out that when working with Exchange via WebDAV, infinite recurrence is actually cut off at an arbitrary point far in the future. This applies to accessing Exchange directly with WebDAV or by using Outlook Web Access, which is based on WebDAV.

First, a little background. For those of you who aren’t aware, when you access data via WebDAV on Exchange, calendar data is actually rendered as RFC 2445 iCalendar data. The iCalendar data has a lot of extra x-name stuff that is specific to Microsoft that allows it to support the additional MAPI information that’s needed for additional properties (that’s OK, RFC 2445 allows it). Anyway, Microsoft also provides a WebDAV-SQL dialect to query the data (not just for iCalendar stuff). This is great, because it lets you offload a lot of your effort for searching through the data on to the Exchange server.

Where things get a bit interested is when you are working with infinitely recurring appointments (recurring appointments without an end date). Internally, iCalendar is fine with this. The infinite pattern can be represented by a single iCalendar event, and everything is good. The twist is that when you search for events for a specific date range, Exchange will give you the parent event that actually represents the infinitely recurring pattern and a single event for each instance of your pattern that falls between your search date range. The single events list themselves as instances via a special property.

The reason for this behavior is most likely OWA. OWA is basically an early implementation of AJAX that has client side Javascript accessing a WebDAV back end. By instantiating all instances of the recurring pattern for you, much work is taken off of the front end for computing when instances of the recurring pattern should go. OWA just queries for a date range that’s either a day, week or month, and it’s given everything it needs. Exchange is even smart, in that once it has received a query for a certain date range, it caches the instance events on the back end and they become visible via WebDAV as separate entities.

The intelligent reader will notice an opportunity for problems here: if Exchange is instanciating and caching all these instances on the fly, a request with an open-ended date range search will never complete. Exchange would just keep instancing more an more instances. To avoid this problem, Microsoft implemented a system where you can only query a bounded date range of up to 2 years. Once you have queried for a specific date range and the results have been cached, open-ended range queries will return already cached instances, but for places where nothing was previously cached, nothing will be returned. Learned that gotcha the hard way.

The second problem with this caching strategy is that if unchecked, it would allow a client of intentionally or otherwise perform a DOS attack on Exchange. A client could continue to query 2 year date ranges forever, and force Exchange to cache more and more instances. To avoid this, Microsoft has implemented a cap as to how far into the future it will allow you to go. From what I can tell, this isn’t documented anywhere, but this is what I have determined experimentally on Exchange 2003:

1. Instances of infinite recurring appointments only seem to expand up until (approx) 10 year after the first date of the recurring meeting. This might actually not be time based, but rather # of occurrences based. I used an infinitely recurring appointment daily and it was about 10 or 11 years.
2. Instances of finite recurring appointment expand arbitrarily to the future, until the end of the prescribed recurrence patter (I only tested this with recurrence patters that have a specified number of recurrences, namely recurring monthly for 999 times, I did not test this with a set end date).
3. OWA suffers from the same limitation. If you try to view an appointment 30 years out for a daily infinite recurrence, it doesn’t show up.

The net result of this is that OWA will show an infinitely recurring appointment stopping sometime in the future, and your WebDAV queries might not return what you expect.

Leopard wants to make sure you’re not just bluffing when you enter your password to access an Exchange WebDAV resource. The first time you enter your password, it will reject it, but then if you just resubmit without changing anything, it will let you in (assuming you actually entered the correct password). I’m not actually sure if this is a problem with OS X or Exchange. Some other people have had trouble with authentication, as has been discussed here.

My work Vista machine periodically looses its ability to copy things to the clipboard.  I run a fairly complicated environment, with multiple virtual machines open at the same time, but still, it’s the stupid clipboard.  It’s been around since the beginning of Windows and I’m running virtual machines in a Windows virtual machine host running a Windows operating system.  Regardless of where you place the blame it goes back to Microsoft.