Date DST inquiry

[acarur01]

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?

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
});

[Isomorphic]

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.

[acarur01]

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.

[Isomorphic]

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.

[Isomorphic]

We've made changes that should address this - please retest with a nightly after tomorrow (1/29 or later).

[acarur01]

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?

[Isomorphic]

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?

[acarur01]

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.