New Posts New Posts RSS Feed: Silverlight Server / Client - Different time zones
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Silverlight Server / Client - Different time zones
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
ajhops View Drop Down
Newbie
Newbie
Avatar

Joined: 23-Aug-2010
Posts: 11 		Post Options Post Options   Quote ajhops Quote  Post ReplyReply Direct Link To This Post Topic: Silverlight Server / Client - Different time zones
    Posted: 16-Feb-2011 at 1:10pm
I don't know how to begin debugging this.

An entity has a date time property. Client is in time zone UTC+13 hours. Server is in time zone UTC - 6 hours.

On the client, when setting the property we always set it to midnight UTC (the field is meant to designate a date only).

Most of the time the field is saved server side with a 00:00:00 time component. Occasionally it is set with a 05:00:00 time component. The weird part is that by "occasionally" I mean only when the field is being set to midnight of today - UTC.

Can anybody help me find definitive facts about how datetime objects are serialized/deserialized between client and server (does devforce do anything special??).

Much Appreciated,
-Adam 
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 16-Feb-2011 at 3:30pm
Hi ajhops;

DevForce does not do anything special with the serialization/deserialization process.

I don't quite follow this statement, "The weird part is that by "occasionally" I mean only when the field is being set to midnight of today - UTC."

In the previous statement, you said "On the client, when setting the property we always set it to midnight UTC".

It sounds like you don't always set the property to midnight UTC? Could you clarify?

Researching more, I found that DateTime object does get stored with different values if the client and server are on different time zones. The recommended practice to deal with this scenario is to use DateTimeKind.Utc and apply a time zone conversion as required.

I came across this article that might be useful for you.

Coding Best Practices Using DateTime in the .NET Framework.

Hope this helps.
Back to Top
ajhops View Drop Down
Newbie
Newbie
Avatar

Joined: 23-Aug-2010
Posts: 11 		Post Options Post Options   Quote ajhops Quote  Post ReplyReply Direct Link To This Post Posted: 17-Feb-2011 at 5:49am
Sorry for the poor wording. I struggled to describe the problem without going into a paragraph long description of our business requirements. Basically, this particular field is always a midnight DateTime. It needs to show midnight in the database, server, client even when all are in different time zones. The user chooses a date on a calendar control to set this field.

After poking around I have some questions that should lead me to an answer. 

Here is the definition of the property:

#region ReportDate property
 
    /// <summary>Gets or sets the ReportDate. </summary>
    [Bindable(true, BindingDirection.TwoWay)]
    [Editable(true)]
    [Display(Name="ReportDate", AutoGenerateField=true)]
    [IbVal.RequiredValueVerifier( ErrorMessageResourceName="IADCHeader_ReportDate")]
    [DataMember]
    public System.DateTime ReportDate {
      get { return PropertyMetadata.ReportDate.GetValue(this); }
      set { PropertyMetadata.ReportDate.SetValue(this, value); }
    }
#endregion ReportDate property
We construct our entity using Manager.CreateEntity<T>
The ReportDate field appears to be auto generated with a DateTime.Now.Date (midnight of today on the client *LOCAL* time). Can anybody verify that this is the designed behavior?
A few lines later I try setting ReportDate to a different DateTime (midnight of today on the client *UTC*) time, this set does nothing. PropertyMetadata.ReportDate.SetValue(this, value); appears to determine that the setter is trying to set the value to what it already is and ignores it (even though datetimekind are different). Can anybody verify this?

I truly appreciate any light the ideablade folks or community can shed on how EF/Devforce handle datetimes and DateTimeKinds.



Back to Top
ajhops View Drop Down
Newbie
Newbie
Avatar

Joined: 23-Aug-2010
Posts: 11 		Post Options Post Options   Quote ajhops Quote  Post ReplyReply Direct Link To This Post Posted: 17-Feb-2011 at 6:36am
I found the problem.

DateTime.Today == DateTime.SpecifyKind(DateTime.Today, System.DateTimeKind.Utc)
evaluates to True. I did not expect this.
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 17-Feb-2011 at 5:16pm
Hi ajhops;

I did some testing in regards to your above questions.

1. "The ReportDate field appears to be auto generated with a DateTime.Now.Date 
(midnight of today on the client *LOCAL* time). Can anybody verify that this is the designed behavior?"

I believe this happens if you don't set your ReportDate field as nullable. In my test, my DateTime field is nullable and upon new entity creation, my DateTime field is set to null. I can then set it to any DateTime object I want.

2. A few lines later I try setting ReportDate to a different DateTime (midnight of today on the client *UTC*) 
time, this set does nothing. PropertyMetadata.ReportDate.SetValue(this, value); appears to determine that the
setter is trying to set the value to what it already is and ignores it (even though datetimekind are 
different). Can anybody verify this?"

I did the same test and encountered the same behavior. As you have verified, it looks like when comparing 2 different DateTime objects, .NET ignores the DateTimeKind and only compares the date and time. In this case, since the midnight part of the DateTime objects are the same, the set does nothing.

3. "I found the problem.
  
DateTime.Today == DateTime.SpecifyKind(DateTime.Today, System.DateTimeKind.Utc) evaluates to True. 
I did not expect this.

Again, it seems that the DateTime object comparison (==) operator ignores the DateTimeKind part of the DateTime object. The following tests below seem to confirm it.

      DateTime utcDt = DateTime.SpecifyKind(DateTime.Today, DateTimeKind.Utc);
      DateTime localDt = DateTime.SpecifyKind(DateTime.Today, DateTimeKind.Local);
      DateTime unspecDt = DateTime.SpecifyKind(DateTime.Today, DateTimeKind.Unspecified);

      bool isTrue1 = (DateTime.Today == utcDt); //true
      bool isTrue2 = (DateTime.Today == localDt); //true
      bool isTrue3 = (DateTime.Today == unspecDt); //true

      bool isTrue4 = (DateTime.Today.Kind == utcDt.Kind); //false
      bool isTrue5 = (DateTime.Today.Kind == localDt.Kind); //true
      bool isTrue6 = (DateTime.Today.Kind == unspecDt.Kind); //false
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down