DateTime is a simple concept as long as you don't think about it. I guess that's true for most things, but I don't want to get too off topic here. When it comes to DateTime mixed with thinking, some annoying questions come up. Such as...
"What happens when the Vault server is in a different time zone as the client?"
"How do cultural settings affect the DateTime value? (Example: 01/31/2010 versus 31.01.2010)"
There are basically two ways that Vault handles DateTime values. Which way is used depends on how the information is being passed to or from the server.
Mechanism 1: DateTime objects
If you are dealing with a DateTime object, life is simple. The object will always reflect the local time. Things like leap year and daylight savings time are automatically taken into account. If the client and server are in different time zones, the web services framework automatically converts things for you.
Example: File.CreateDate. This value will always be the time in your local time zone. Even if somebody from another time zone created the File, you will see the CreateDate as if the File was created from your time zone.
Mechanism 2: DateTime strings
Sometimes the DateTime value needs to be passed as a string. In this case, the web services framework will not help you. The Vault solution is to convert to Universal Time then write out the value in a specific format. Specifically, "MM/dd/yyyy HH:mm:ss" is the time format. It's OK if this format doesn't match your current culture's format. The point is for the Vault client and server to use a common format.
Example: When doing a search on a DateTime value, you need to call ToUniversalTime().ToString("MM/dd/yyyy HH:mm:ss") on the DateTime object you are using. PartialMirrorCommand.cs in the Vault Mirror sample has an example of this search.