Let me show you a small unit test
1 [Test]
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized, Is.EqualTo(date));
8 }
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized, Is.EqualTo(date));
8 }
How do you think it will behave? I'll surprise you: it fails.
The reason of such a strange behavior is described here. The main point is that deserialization assumes the value is serialized using GMT time.
Ok, that's funny, but how exactly it can affect TargetProcess? We're moving to REST little by little, but there are still many places where client javascript code communicates with TP server through web services using the power of ScriptServiceAttribute. Guess how the data passed to server is deserialized?
So, please be careful when accessing DateTime objects passed from client javascript and don't forget to convert it to local time as I would do to make my test pass.
1 [Test]
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized.ToLocalTime(), Is.EqualTo(date));
8 }
9
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized.ToLocalTime(), Is.EqualTo(date));
8 }
9
Комментариев нет:
Отправить комментарий