Home » Eclipse Projects » Eclipse Scout » Differences between date fields(DateField, DateTimeField, UTCDateField)
| | | | |
| Re: Differences between date fields [message #1004813 is a reply to message #1004425] |
Wed, 23 January 2013 23:06   |
 Lukas Huser
Messages: 42
Registered: March 2010 |
Member |
|
|
Hi all
Urs, thanks for bringing up this topic.
First, let's have a closer look at how the Scout framework treats java.util.Date objects in contrast to UTCDate (org.eclipse.scout.commons.UTCDate) objects.
Second, I will make a point that the current default behavior for java.util.Date is problematic in many cases where systems in different time zones are involved.
Third, we will hopefully find a good solution to improve the current situation.
Current Situation
java.util.Date objects are manipulated by the Scout framework when transferred between client and server: a java.util.Date object is replaced by a static date (org.eclipse.scout.rt.shared.servicetunnel.StaticDate) during serialization. A StaticDate is "time zone and daylight saving time independent", you can think of it similar to a string representation, such as "15:00", which does not change when displayed on other systems. Any information regarding the time zone is lost, a StaticDate is always implicitly interpreted in the systems' current time zone.
Or in other words: A date is always displayed exactly the way as it would be on the system that created it!
UTCDate objects are not treated in any specific way by the Scout framework. They represent a given point in time, encoded as the offset in milliseconds to the 'epoch' January 1, 1970, 0:00:00 UTC.
So they behave just as you would expect of normal java.util.Date objects.
If the same date is displayed on two systems in different time zones, you will have two different representations.
Example
(Note: when talking about 'dates', we're actually talking about its time part here. It's the time part that matters in this context.)
Date
Server UTC+0 Client1 UTC+1 Client2 UTC+2
--------------------------------------------------------------
d = new Date()
"15:00" UTC+1
<-- "15:00" --
"15:00" UTC+0
--------------- "15:00" ------------->
"15:00" UTC+2
UTCDate
Server UTC+0 Client1 UTC+1 Client2 UTC+2
---------------------------------------------------------------
d = new UTCDate()
"15:00" UTC+1
<----- d -----
"14:00" UTC+0
----------------- d --------------->
"16:00" UTC+2
Problems
The current design is certainly counter-intuitive and contradicts the principle of least surprise (java.util.Date is silently treated as StaticDate, UTCDate behaves like a normal java.util.Date would). Any problems that might occur (and they will...) due to the special treatment of java.util.Date objects are really hard to track down...
I understand that there are use cases where a StaticDate might be desired. This could be the case if the client itself moves between different time zones.
If I set an alarm clock to "08:00", I might not care in which time zone I'm located, I want to be alarmed at "08:00" in the time zone that I just happen to be.
As the Scout framework currently does not support to explicitly set a time zone on a DateField, this might seem to be a reasonable behavior.
However, in many cases StaticDates are not desired and can lead to problems.
You will run into problems if your server and your clients are located in different time zones. You will have inconsistent dates as soon as you
create new Date objects on client side as well as on server side. This happens easily: Imagine a Task entity which has a due date (chosen by the user on client side).
You also might attach a 'last change date' on server side when storing changes to the task entity. The last change date will be shown to the users as if being in the time zone of the server.
Or worse, you monitor the due date on server side and automatically trigger some actions if its due date is reached (of course, the action will be triggered at the wrong time).
java.util.Dates are treated as static dates only when transferred between client and server. They are de-serialized back to normal java.util.Dates (and therefore are attached to a time zone again). If you persist date values on the server (which is not uncommon for Scout applications  ) you effectively store a differerent point in time than sent by the client! To correctly support static dates, they must also be persisted in a time zone independent manner.
Currently, if you happen to move your database to a different server in a different time zone, all your stored date values are garbage (or more precisely: they are
displayed wrong on the clients).
Variations of the persistency example occur in different flavors: You might get wrong dates if you sync your Date objects with third party systems (e.g. when synchronizing server side generated dates on client side etc.). Also, if you use multiple application servers (load balancing) accessing the same database, you better have all application servers in the same time zone...
The only way you can opt-out from the default behavior is by using the UTCDate class.
Note that it is not enough to just replace DateField by UTCDateField, as any java.util.Date object is replaced by a StaticDate.
For example, you would also need to convert all Dates to UTCDates when loading data for table pages, or any other Date objects involved in remote service calls.
Solution
I understand that such a default behavior cannot easily be changed, because existing systems might rely on the current behavior.
However, I'm also sure that the current behavior will lead to problems and data corruption. I'ts merely a matter of time...
I could imagine that the solution will include the following:
1) Do not treat java.util.Date objects as StaticDates by default (maybe provide a switch to enable it for legacy support). StaticDates should be opt-in, not opt-out.
2) Time zone support on DateFields. I.e. enhance the DateField to allow to explicitly chose a time zone.
3) Full support for StaticDates. Requires that StaticDates are also correctly persisted in a time zone independent manner.
While I think that point 1) is crucial and point 2) is a desireable enhancement, point 3) is not a real issue for me.
Well, the whole topic is rather complex, I also might have missed some crucial point. I'm really interested in what other people think on this topic!
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 23:45:16 GMT 2024
Powered by FUDForum. Page generated in 0.04172 seconds |
] 
Search
Help
Register
Login
Home
