I have a .NET WCF service with a few operation contracts that takes a DateTimeOffset. The idea is to avoid any confusion with DST and time zones.

However I am in doubt that using DateTimeOffset is a good idea after all, since it is fairly non-standard and would cause headaches for anyone trying to connect with, say, a Java application or a .NET application bound to an older .NET version.

An alternative is to expect a UTC DateTime, but this introduces the risk that someone will forget to use UTC time and call the service with a local time.
I could also expect a local time DateTime, since clients will always be in the same timezone, but this leaves some subtle, but classic, ambiguity around DST changes.

Does anyone have headache stories with DateTimeOffset in a service interface or is it relatively unproblematic to use after all?

So basically, DateTime is serialized as a standard xs:dateTime (which does have the correct timezone component) and DateTimeOffset is serialized into a non-standard complex type, which the caller would have to understand and handle correctly.

FWIW; Since I found this out, I will probably use DateTime for the WCF interface unless I actually need to take care of different timezone offsets.

Currently, the only justification I could see in favour of using the complex type (since xs:dateTime should be able to contain all information that it does!) is that if xs:dateTime had been used to serialize DateTime and DateTimeOffset, a WCF client would have no idea which type to use.