You're right, it would be best to avoid the "magic". The reason we didn't use the nullable date type is that an .xsd is the root definition of our data structure for inport/export from the program. Then we xsd.exe code gen a structure of classes (from this .xsd) to represent this data, deserialize xml into these classes, and finally map this data to the data-layer to be sent to the database.
I just checked, and I believe we should be able to set the "isnillable" on the .xsd elements to have xsd.exe generate them as nullable time. But I'm going to need to look at how an "isnillable" xsd.exe generated nullable type is serialized/deserialized from the xml.
I did find a posting on stackoverflow.com about the "nillable", but sounds like an issue with getting the nullable type to serialized/deserialize as one would hope:
I believe if you add nillable="true" in your XML schema definition, XSD will create a nullable type for that element. This is probably a good idea anyway, since you are implying that this value is indeed nillable and this would make your schema definition more explicit in that regard.
Unfortunately, it still includes the corresponding "Specified" field in this case. If you want the serializer to obey the nullable value directly, you will need to manually remove the "xxSpecified" column from the generated code.
