Remoting (AMF3) uses Universal Time Coordinate (UTC) date format (the number of milliseconds that have passed since midnight, January 1, 1970 Greenwich Mean Time). The AMF3 protocol does not include information about the time value's offset from the Universal Time.
![]() |
The primary advantage of storing date/time values in UTC is that it makes the data transportable. UTC time provides a universal point of reference by which all time zones are offsetted from. UTC is an ideal choice for storing date/time formats in a web application when the web server and its users might reside in different time zones. |
Pitfalls of using server time are for example if you have multiple servers in multiple time zones or you are moving from a web hosting company to another, situated in different time zone.
![]() Flex application |
![]() Internet/AMF |
Gateway |
![]() Application server |
Date value (client local time) |
UTC date/time |
[TimezoneCompensation None] |
UTC date/time (DateTimeKind.Utc) |
Date value (client local time) |
UTC date/time |
[TimezoneCompensation Auto - not suitable for AMF3] |
UTC date/time (DateTimeKind.Utc) |
Date value (client local time) |
UTC date/time |
[TimezoneCompensation Server] |
Date/time in servers's time zone (DateTimeKind.Local) |
![]() Application server |
Gateway |
![]() Internet/AMF |
![]() Flex application |
DateTime instance |
Convert to UTC using ToUniversalTime() |
UTC date/time |
Date value (client local time) |
The sample application tracks when a record was created and an appointment updated, with the following database schema (this sample uses SQL Server specific features)
| Column | Data Type |
|---|---|
EmployeeID |
int - Primary Key and AutoIncrement |
FullName |
varchar(50) |
DateCreated |
datetime |
DateAppointment |
datetime |
Creating a new record
The INSERT statement used by the application can use the SQL Server's built-in getutcdate() function
INSERT INTO [Employees] ([FullName], [DateCreated]) VALUES (@FullName, getutcdate())
or another option is to specify a DateCreated parameter (@DateCreated) set to DateTime.UtcNow
Updating a record
The gateway will be configured with time zone compensation none (default value) the appointment date is recived as UTC date/time, the application executes the following UPDATE statement
UPDATE [Employees] SET [FullName] = @FullName, [DateAppointment] = @DateAppointment WHERE [EmployeeID] = @EmployeeID
where the DateAppointment parameter's value is the date received from the client.
Retrieving data
When returning DateTime instances use DateTime.SpecifyKind() to explicitly set how the date will be affected by the gateway conversion.
When retrieving data from the database your DateTime instances will have the DateTime.Kind property set as Unspecified (even if your dates are stored as UTC in the database). To have the correct flag set and to avoid the gateway to convert the dates, fetch the schema and specify the correct DateTimeMode for date columns.
SqlCommand command = new SqlCommand("SELECT EmployeeID, FullName, DateCreated, DateAppointment FROM [Employees] ...", connection);
SqlDataAdapter adapter = new SqlDataAdapter(command);
DataTable result = new DataTable();
adapter.FillSchema(result, SchemaType.Source);
result.Columns["DateCreated"].DateTimeMode = DataSetDateTime.Utc;
result.Columns["DateAppointment"].DateTimeMode = DataSetDateTime.Utc;
adapter.Fill(result);
return result;
Time zone info
Depending on your application in some cases you may need to display date fields without translating to the client's local time.
If the local time perspective is important, store your dates in UTC along with the current local time zone offset in another field.
For example consider an application where you are retrieving events (news) that took place in a specific time zone and it does not make sense to list them in the client's local time.
The remoting service should retrieve both fields so the client can translate all the dates to the original time zone.