Go Back   SmartClient Forums > Technical Q&A
Wiki Register Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread
  #1  
Old 19th Jan 2012, 10:07
acarur01 acarur01 is offline
Registered Developer
 
Join Date: Dec 2008
Posts: 1,413
Default Date DST inquiry

We are facing issues with selecting Nov6 and Nov7. If selected date crosses Daylight Saving Time boundary, hour is offset.
2011's Daylight Saving ends Nov 6. When selecting 2011/11/07 (when system date is within the same daylight saving configuration like 2012/11/06), the default hour is 00:00
However, when selecting 2011/11/06 (still in daylight saving time), the default hour is 01:00 (one hour ahead). Is this intended behaviour or is this a bug?


Code:
isc.DynamicForm.create({
    ID: "dateForm",
    numCols: 2,   
    width: 600,
    fields: [
        {width: 400, name:"directInputDate", title:"Direct Input Date", _constructor: "DateItem", useTextField:true, change:"dateLabel.setContents(value)",
                              dateFormatter: "toString"
}
    ]
});
 
isc.Time.adjustForDST=false;
isc.Label.create({
        ID: "dateLabel",
        top: 40,
        left: 100,
        width: 400
});
Reply With Quote
  #2  
Old 20th Jan 2012, 19:02
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,316
Default

Short answer: There are cases where this could occur, and this example code isn't entirely valid, but it looks like you may have encountered a framework issue here. We'll investigate on our end.

Longer answer:
SmartClient has separate handling for logical "date" values vs "datetimes"
The concept is that a "date" is a logical date on a calendar, not an instant in time, and has no meaningful 'time' information associated with it.
We use JavaScript date objects to manipulate these logical dates in memory but the time portion is essentially ignored.

"datetimes" on the other hand refer to an instant and include meaningful time information.

This is specified by the field.type (for databound components this is usually set at the dataSource level).
Check out this documentation topic for a full discussion of this area:
http://www.smartclient.com/docs/8.2/...rmatAndStorage

When you pick a value from the dateChooser, if the field is of type datetime (or unspecified) we default the time portion to 00:00 in the display timezone.
There are cases where this is not an option - in some timezones the DST offset occurs at midnight so the times literally jump from 23:00 to 01:00 and as such we may have to adjust the time to ensure the date displays correctly.

However it looks like something else is going on in your test case. We're taking a look.
As a side note: This isn't a strictly valid usage -- the DateItem expects to be able to parse the entered value into a date so you'd typically want to specify a standard formatter for which we have a parser function, so the user can edit the text value and we can still get a valid date or datetime object out of the item.
Reply With Quote
  #3  
Old 23rd Jan 2012, 04:13
acarur01 acarur01 is offline
Registered Developer
 
Join Date: Dec 2008
Posts: 1,413
Default

We actually do set our own dateFormatter as we as our own inputFormat which spit out proper date objects - but I didn't think it would be necessary to add since we are able to reproduce with a simple testcase. If you would still like this, please let me know and I will tweak the standalone.
Reply With Quote
  #4  
Old 24th Jan 2012, 10:15
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,316
Default

One of our engineers is scheduled to look at this. If it's not difficult to modify the standalone to demonstrate it we'll be happy to look at that as well to ensure we resolve the exact issue you're hitting.
Reply With Quote
  #5  
Old 28th Jan 2012, 02:31
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,316
Default

We've made changes that should address this - please retest with a nightly after tomorrow (1/29 or later).
Reply With Quote
  #6  
Old 30th Jan 2012, 04:35
acarur01 acarur01 is offline
Registered Developer
 
Join Date: Dec 2008
Posts: 1,413
Default

Just tested with 2012-01-30 build and I am not seeing any difference in behaviour from what I had originally described - what exactly was fixed?
Reply With Quote
  #7  
Old 30th Jan 2012, 07:09
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,316
Default

The change we made was to ensure that the actual DST changeover dates don't misreport off-by-one times (ie, 01:00 rather than 00:00 on 11/6/2011). That change has indeed been present since 1/29, and works fine - assuming you are allowing adjustments for DST.

You're switching adjustForDST off in your example below, so it's reporting unadjusted times.

Can you clarify why you don't want those adjustments and what you expect to see?
Reply With Quote
  #8  
Old 30th Jan 2012, 07:26
acarur01 acarur01 is offline
Registered Developer
 
Join Date: Dec 2008
Posts: 1,413
Default

Ah ok. We had set this flag to false a while back to fix a reported bug with dates rolling over - I'll re-evaluate that old ticket first and if it still makes sense to do so.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search


Similar Threads
Thread Thread Starter Forum Replies Last Post
SC_SNAPSHOT-2012-01-07_v82p missing files and not working RickBollinger Installation 23 13th Jan 2012 08:42
Date.setInputFormat issue (date as dateTime) alirioperez Technical Q&A 7 6th Dec 2011 12:16
DateTimeItem problem with picking date across DST dczech Smart GWT Technical Q&A 2 26th Jul 2010 12:23
Display of date is wrong! ghost277 Smart GWT Technical Q&A 2 26th Jul 2010 12:22
Date validator fails on a datasource wgandhi Smart GWT Technical Q&A 0 2nd Jun 2009 22:08

© 2010,2011 Isomorphic Software. All Rights Reserved