| Differences between date fields [message #1001772] |
Thu, 17 January 2013 05:54  |
Eclipse User |
|
|
|
I've been experimenting with the date and time related form fields.
As far as I can tell, the only difference between DateField and DateTimeField is that the latter has a hard coded getConfiguredHasTime() method that always returns true. Is this class purely a convenience class or are there any other differences that I am missing?
Also, what is the difference between DateField and UTCDateField? I've failed to see a difference in behaviour either on the UI or on the server side examining the formData members.
|
|
|
|
|
|
|
| Re: Differences between date fields [message #1004813 is a reply to message #1004425] |
Wed, 23 January 2013 18:06  |
| Eclipse User |
|
|
|
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!
|
|
|
|
| Re: Differences between date fields [message #1004949 is a reply to message #1004931] |
Thu, 24 January 2013 02:43 |
| Eclipse User |
|
|
|
From my point of view there are two main cases. On one hand dates without any timezone information (e.g. birthdays), their displayed value shouldn't change when being shown on different systems (some webservice libraries are really hard to work with, because you can't enable or disable automatic timezone conversions). On the other hand dates/datetimes with timezone information. For the latter it is important that timezone dependent calculations can be performed and that it is possible to choose whether to display their value in the local timezone, a chosen timezone or the timezone of the source/server.
Probably we could use one of the many libraries out there promising a good solution? Or the new Java 8 date API? I don't know them very well, so I'm not partial to any of them.
|
|
|
Powered by
FUDForum. Page generated in 0.05838 seconds
Home