Skip to main content
Published: November 16 2006, 10:23:00 AMUpdated: November 28 2020, 3:02:22 PM

DateTime values have a very specific behavior in .NET when it comes to serialization of a value when an API call is made.
This Knowledge Base entry describes the behavior when using the .NET SDK, and how best to work with the DateTime fields.

Detailed Description

When setting DateTime values using .NET 1.0 or 1.1, the serialized (actual XML sent in the API call) value is always in the local time zone of the computer.
In .NET 2.0, this behavior may be different (, and result in SDK DateTime values to be serialized out in UTC (also referred to as GMT).
The following illustrates the situation when using .NET 1.0 or 1.1 (using the TimeFrom and TimeTo properties):

I assign "2006-02-08 12:00:00" to a DateTime field, such as ModTimeFrom in the GetSellerTransactions call.
If my server that is running the application is in the Pacific Time Zone and on PST,
then the call made by application will show the following in the log:
The SOAP API will effectively treat this as 2006-02-08 20:00:00 GMT when processing the call.

Similarly, if the local time zone on the server running the application is EST,
and "2006-02-08 12:00:00" is assigned to a DateTime field,
then the log will show the following:
The SOAP API will effectively treat this as 2006-02-08 17:00:00 GMT when processing the call.

The recommended action is to have all machines which make API calls to be set to the same time zone for the system time,
and to have this common time zone be GMT.
Instead of using the TimeFrom and TimeTo properties, please make a point of it to use TimeFromUTC and TimeToUTC.
Using the UTC properties means that the actual time value serialized out will always be the actual time value you are setting.
You do not have to worry about the offset that happens when the value is serialized out,
since the UTC value you are setting is the value that the API servers will use when processing the call.

By doing this, the actual time values assigned to the DateTime properties will already be in GMT, always.
You should also be storing datetime values in your database in GMT.
This will reduce confusion and keep consistency across your servers, application code and databases.
Any customer facing datetime values can be adjusted as needed by "presentation layer" application code.
The presentation layer code will also be consistent since it will deal with the same datetime values from your common datasource format.

Additional Resources

How well did this answer your question?
Answers others found helpful