locked
DateTime Time zone problem RRS feed

  • Question

  • I have a problem with passing DateTime with RIA services.

    Here is a simple scenario to explain the problem:

    POCO object to be filled:

        public class Item
        {
            [Key]
            public Guid ID { get; set; }
            public DateTime Date { get; set; }
            public string Text { get; set; }
        }

    My Domain service:

        [EnableClientAccess()]
        public class MyDomainService : DomainService
        {

            public IQueryable<Item> GetItems(DateTime dateFrom)
            {
                //Sample item
                Item myItem = new Item();
                myItem.ID = Guid.NewGuid();
                myItem.Date = dateFrom;
                myItem.Text = "Sample item";

                List<Item> sampleData = new List<Item>();
                sampleData.Add(myItem);
                return sampleData.AsQueryable();
            }

        }

    Client call:

                MyDomainContext myContext = new MyDomainContext();
                myContext.Loaded += new EventHandler<System.Windows.Ria.Data.LoadedDataEventArgs>(myContext_Loaded);
                myContext.LoadItems(new DateTime(2009, 1, 1));

    Now here is my problem:

    In the GetItems method the myItem.Date has a value of (2009/01/01-00:00:00) (same date as on client).

    But in the myContext_Loaded, the item has a value of (2008/12/31-23:00:00)

    I guess this is because there is another time zone on the server? But why was there no difference when the client calls the server in the get method?

    What's the best solution for that kind of problem?

    Sunday, May 10, 2009 8:45 AM

Answers

  • That's your problem then. If the two endpoints communicate in different timezones, the DateTime you create on the client will be in that of the client's timezone, and likewise for the server. This is technically correct though. If I enter my current time as 1pm on the client, to the server that might mean 3pm, but it will correctly convert the received date to 3pm when it receives it. In your case that is a problem, so you MUST explicitly declare a common timezone in that case when you create the DateTime instance.
    Or in other words: You cannot create a DateTime instance WITHOUT a timezone.
    Monday, May 11, 2009 3:39 AM
  • After several investigations I found out the following:

    (1) Calling Get/Load Methods of the domainservice

    no matter which DateTime.Kind you specifiy on the client's domaincontext, the domainservice will use the same date with the DateTimeKind "Unspecified". e.g.

    - Client Date "07/20/2009 Local" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Utc" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Unspecified" becomes "07/20/2009 Unspecified" on the Server

    This is a bug in my opinion. I ended up correcting the date like this: mydate = new DateTime(myDate.Ticks, DateTimeKind.Utc); (in case myDate on client was of kind UTC)

    (2) Returning Data to the DomainContext

    - The Dates that are returned from the server always get the kind UTC on the DomainContext. Thus, you have to convert it back to local time if you want to display the data.

    (3) There is a property "UsesUtcDateTimes" on the domain service which controls the UTC conversion behavior and can be overridden. But it doen't seem to make a difference if it's true or false. My guess is that it's not even implemented, yet.

    My solution:

    Since I can't influence (2), I always use Dates of kind UTC in the clients and server code logic (to get around the bug in (1) i am setting the correct date in a helper function). To display the data I am using a UTC<->Local Converter and reference it in all XAML Files which display dates.

    Thursday, July 23, 2009 6:42 AM

All replies

  •  How were the dates created? Did you explicitly specify a timezone at both ends?

    Sunday, May 10, 2009 7:14 PM
  • No, nor on the client neither on ther server. I just use DateTime without a Time zone. However I am using the same machine for client and server at the moment. Is this an IIS setting on server side?

    Actually I don't even need the Time of the DateTime. But due to the different time zones (?) I am getting different dates.

    Monday, May 11, 2009 3:31 AM
  • That's your problem then. If the two endpoints communicate in different timezones, the DateTime you create on the client will be in that of the client's timezone, and likewise for the server. This is technically correct though. If I enter my current time as 1pm on the client, to the server that might mean 3pm, but it will correctly convert the received date to 3pm when it receives it. In your case that is a problem, so you MUST explicitly declare a common timezone in that case when you create the DateTime instance.
    Or in other words: You cannot create a DateTime instance WITHOUT a timezone.
    Monday, May 11, 2009 3:39 AM
  • I’m having the other way around situation, the time component for the smalldatetime data that is currently in the database is let say 6/10/2009 12:00AM but when I’m getting that date on the client side I simply have 6/09/2009 11:00PM.

    I really need some convenient way to get rid of that time-zone aware offset between the server and the client.

    It seems that this post http://silverlight.net/forums/p/94261/215941.aspx#215941 offers some workaround when working with LINQ to SQL (hope that this is the same with LINQ to Entities). It seems that the auto generated is being edited but this probably means that all the changes will be lost once the rebuild is made. I'm wondering whether there is some better way to avoid this data conversion, probably declaratively as soon some Entity is added into the edmx model or maybe later when the corresponding domain service methods are being created for that Entity.

    Sunday, June 14, 2009 2:03 AM
  • I have the same problem with EntityFramework and RIA Services, any solutions?
    Tuesday, July 7, 2009 11:09 PM
  • After several investigations I found out the following:

    (1) Calling Get/Load Methods of the domainservice

    no matter which DateTime.Kind you specifiy on the client's domaincontext, the domainservice will use the same date with the DateTimeKind "Unspecified". e.g.

    - Client Date "07/20/2009 Local" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Utc" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Unspecified" becomes "07/20/2009 Unspecified" on the Server

    This is a bug in my opinion. I ended up correcting the date like this: mydate = new DateTime(myDate.Ticks, DateTimeKind.Utc); (in case myDate on client was of kind UTC)

    (2) Returning Data to the DomainContext

    - The Dates that are returned from the server always get the kind UTC on the DomainContext. Thus, you have to convert it back to local time if you want to display the data.

    (3) There is a property "UsesUtcDateTimes" on the domain service which controls the UTC conversion behavior and can be overridden. But it doen't seem to make a difference if it's true or false. My guess is that it's not even implemented, yet.

    My solution:

    Since I can't influence (2), I always use Dates of kind UTC in the clients and server code logic (to get around the bug in (1) i am setting the correct date in a helper function). To display the data I am using a UTC<->Local Converter and reference it in all XAML Files which display dates.

    Thursday, July 23, 2009 6:42 AM
  •  Hi,

    I just created the following workaround which works fine for me.

    It converts a DateTime field on the client side (in my silverlight app) to the local time zone whenever it is changed.To achieve this,  I created a partial class for every entity that has one or more DateTime fields. For each DateTime field in the entity I implement the method "On<DateTimeField>Changed" method. In these methods I perform the conversion.

    Here is an example:

    public partial class CalendarEntry {
    partial void OnDateChanged() {
    if (Date.Kind != DateTimeKind.Local)
    _date = Date.ToLocalTime();
    }
    }

    This workaround does not require editing any generated code, as is the case in some alternatives that mentioned elsewhere.

    I hope this helps.

     

    Thursday, August 20, 2009 10:29 AM
  • Actually I don't even need the Time of the DateTime.

    Interesting issue: another problem is the fact that your domain model(/service) requires a date and not a date time. It would have been nice if we specialize entity property types, so you're able to return a custom Date struct instead of the simple type DateTime. I could imagine a special type for doubles/decimals as well. You can constrain strings, but yo can't constrain numeric values (think of an amount, which is expressed in 0, 2 or 3 decimals based on the currency). What do you do with the remainder when the client passes in $200,20900000001 instead of $200,20?

    Thursday, August 20, 2009 1:01 PM
  • (1) Calling Get/Load Methods of the domainservice

    no matter which DateTime.Kind you specifiy on the client's domaincontext, the domainservice will use the same date with the DateTimeKind "Unspecified". e.g.

    - Client Date "07/20/2009 Local" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Utc" becomes "07/20/2009 Unspecified" on the Server

    - Client Date "07/20/2009 Unspecified" becomes "07/20/2009 Unspecified" on the Server

    This is a bug in my opinion. I ended up correcting the date like this: mydate = new DateTime(myDate.Ticks, DateTimeKind.Utc); (in case myDate on client was of kind UTC)

    (2) Returning Data to the DomainContext

    - The Dates that are returned from the server always get the kind UTC on the DomainContext. Thus, you have to convert it back to local time if you want to display the data.

    (3) There is a property "UsesUtcDateTimes" on the domain service which controls the UTC conversion behavior and can be overridden. But it doen't seem to make a difference if it's true or false. My guess is that it's not even implemented, yet.

     

     Are these observations RIA Service bugs or features? If they are bugs, when are they going to be fixed?

     

    Tuesday, October 6, 2009 3:39 AM
  • Tuesday, December 22, 2009 4:29 AM