Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Differences between date fields(DateField, DateTimeField, UTCDateField)
Differences between date fields [message #1001772] Thu, 17 January 2013 10:54 Go to next message
Urs Beeli is currently offline Urs Beeli
Messages: 330
Registered: October 2012
Location: Bern, Switzerland
Senior Member
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 #1001807 is a reply to message #1001772] Thu, 17 January 2013 12:01 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 701
Registered: October 2011
Senior Member
* DateField vs DateTimeField

I think you are right: DateTimeField is a convinence DateField. It is written in the JavaDoc and on the wiki:

http://wiki.eclipse.org/Scout/Concepts/DateField

http://wiki.eclipse.org/Scout/Concepts/DateTimeField
http://wiki.eclipse.org/Scout/Concepts/TimeField


* DateField vs UTCDateField

This is probably not so good documented. I know that this was introduced because of a problem with the same application beeing opended on different Time Zone.

Sometime you want to express "17.01.2013 1:00 PM" independently from the time zone, and sometime you want to express "17.01.2013 1:00 PM UTC +1" and have this date+time be changed depending on the time zone where you open your application.

I think that this is why there is 2 date fields...

Maybe can somebody tell more.

Re: Differences between date fields [message #1003428 is a reply to message #1001807] Mon, 21 January 2013 08:13 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 330
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Jeremie Bresson wrote on Thu, 17 January 2013 13:01
* DateField vs UTCDateField

This is probably not so good documented. I know that this was introduced because of a problem with the same application beeing opended on different Time Zone.

Sometime you want to express "17.01.2013 1:00 PM" independently from the time zone, and sometime you want to express "17.01.2013 1:00 PM UTC +1" and have this date+time be changed depending on the time zone where you open your application.

I think that this is why there is 2 date fields...


Thanks for your answer. I can see your point about the different representations of a time but I still fail to see the effect. In the clients, the two fields represent the time exactly identically (21.01.2013) without any way to indicate that one would be UTC based. On the data side, as far as I can tell UTCDate is an extension of Date which adds no further functionality.

Jeremie Bresson wrote on Thu, 17 January 2013 13:01

Maybe can somebody tell more.


Hopefully Smile
Re: Differences between date fields [message #1004059 is a reply to message #1003428] Tue, 22 January 2013 14:07 Go to previous messageGo to next message
Judith Gull is currently offline Judith Gull
Messages: 49
Registered: February 2010
Member
I updated the javadoc for AbstractDateField and AbstractUTCDateField. I hope this answers your questions.

See http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/tree/org.eclipse.scout.rt.client/src/org/eclipse/scout/rt/client/ui/form/fields/datefield/AbstractDateField.java
Re: Differences between date fields [message #1004425 is a reply to message #1004059] Wed, 23 January 2013 07:59 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 330
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Judith Gull wrote on Tue, 22 January 2013 15:07
I updated the javadoc for AbstractDateField and AbstractUTCDateField. I hope this answers your questions.

See http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/tree/org.eclipse.scout.rt.client/src/org/eclipse/scout/rt/client/ui/form/fields/datefield/AbstractDateField.java


Not really, no Smile

In the sample included with the javadoc it says:
"The two println statements result in the same value on server and client independent of the timezone of the client and server."

That makes sense. It also says: "AbstractUTCDateField can be used instead, if this is not the desired behavior."

However, I'm still not clear, what behaviour would be exhibited by using UTCDateField instead. Unfortunately I couldn't find any javadoc on that class. Can you elaborate a bit more what would happen if the same example you used for DateTimeField were using UTCDateField instead?

Sorry for being dense Wink
Re: Differences between date fields [message #1004813 is a reply to message #1004425] Wed, 23 January 2013 23:06 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas Huser
Messages: 41
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 Smile) 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 #1004931 is a reply to message #1004813] Thu, 24 January 2013 06:55 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 330
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Lukas, thank you for explaining this so clearly. I think your explanation above would be a good addition to the DateField and UTCDateField Wiki pages!

It also explains, why I didn't see any difference between DateField and UTCDateField, because both my server and client are in the same time zone (my expectation was that the UTCDateField would explicitely display the time zone information or something like that, I never got as far as thinking about clients in different time zones)
Re: Differences between date fields [message #1004949 is a reply to message #1004931] Thu, 24 January 2013 07:43 Go to previous message
Arthur vD is currently offline Arthur vD
Messages: 50
Registered: March 2010
Member
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.
Previous Topic:MessageBox dimensions
Next Topic:How to use SnapBox
Goto Forum:
  


Current Time: Fri Sep 19 17:58:08 GMT 2014

Powered by FUDForum. Page generated in 0.10705 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software