Scout/Concepts/DateField

From Eclipsepedia

< Scout‎ | Concepts
Revision as of 03:16, 7 March 2013 by Urs.beeli.sbb.ch (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Scout
Wiki Home
Website
DownloadGit
Community
ForumsBlogTwitter
Bugzilla
Bugzilla


Specific type of value field to represent Date.

  • implements: I obj.pngIDateField
  • extends: C obj.pngAbstractDateField

Contents

Description

Among the different types of data supported by scout, the DateField is made to represent Date.

The functions:

  • setValue(value)
  • getValue()

use directly Date.

Differences between DateField and UTCDateField

On the UI side there is no difference to be seen between a DateField and an UTCDateField (especially, even if the name might imply this, there is no mechanism to manually set a time zone on an UTCDateField). The difference is in how the contained date and time are treated when such a field is accessed in applications in different time zones.

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


Note.png
Problematic behaviour
The current default behavior for java.util.Date is problematic in many cases where systems in different time zones are involved, a discussion on how this could be resolved in Scout is being held in this forum thread


Screenshot

RAP SWT Swing Swing Rayo
Scout 3.8 DateField RAP.png Scout 3.8 DateField SWT.png Scout 3.8 DateField Swing.png Scout 3.8 DateField Swing Rayo.png

Properties

Defined with getConfiguredXxxxxx() methods.

See also the Field and the Value field pages for the properties that all fields have in common.


Events

Defined with execXxxxxx() methods.

See also the Field and the Value field pages for the events that all fields have in common.


See Also