DateTimeItem picker selects wrong date for time 00:00

[khkwang]

Version: "v9.0_2013-07-03/LGPL Development Only"
Browser: Firefox 26.0

Basically, when a DateTimeItem has a value with time 00:00 and the user clicks on the DateTimeItem picker, the picker automatically selects the day prior.

Steps to reproduce:
1) On a DateTimeItem, click on the Date picker and select a date with time 00:00 (e.g. March 13, 00:00)
2) The time for the field will display the correct date/time
3) Click the picker again and you'll see that the day prior is now selected (e.g. March 12, 00:00)
4) Click on apply, and now the date will be the day prior
5) Repeat steps 3-4 multiple times and the date will keep travelling backwards

Expected:
The picker should not set the date to the one before. If I choose March 13, 00:00 and click on the picker again, it should preselect March 13, 00:00. Not March 12, 00:00.

---------------------------

This issue also translates over to the setDefaultChooserDate() functionality. If I set the default date as March 13, 00:00 and select the date picker, the preselected date will not be March 13, 00:00 as I expect but rather March 12, 00:00.

Please, any advice on how to work around this issue in the meantime or perhaps an estimate of when this might be resolved would be amazing.

Thanks!

---------------
Edit: The same issue occurs for the DateTime picker for ListGrids.

[Isomorphic]

Your build is more than 6 months old - you need to update to the latest from smartclient.com/builds

[khkwang]

I thought that might have been the issue so I updated to version 4.1 through Maven and I'm still having the same issues.

I've also just realized that this issue isn't limited to just picking 00:00. The same issue appears to happen for any times between 00:00 and 03:59.

If it makes any difference, I am in an EDT timezone and the following settings have been made on the application:

DateUtil.setDefaultDisplayTimezone("-00:00");
DateUtil.setAdjustForDST(false);

---------------------

Edit: So apparently EDT is -4 hours from GMT... so this must be some sort of timezone related issue.

Any advice?

--------------------

Edit:

Okay, I did my best to debug through the code and it seems that this.getValue() on the datetimeitem returns EST/EDT time and thus "_2.getDate()" produces the wrong value sometimes (it considers the EST date rather than the UTC one). I thought this was supposed to be dealt with with the DateUtil.setDefaultDisplayTimezone("-00:00"); setting...

[khkwang]

I was hoping I'd get some sort of response by now, but after debugging through the underlying JS code, I seem to be working towards a viable solution (which I doubt is the correct way of doing things, but this is as far as I can go without in depth knowledge of the code base).

In the ICS_Forms.js file there is an function "this.picker.setData" that sets the chosen date to _1.

For my purposes, the issue I was having was fixed setting:

this.chosenDate = new Date(_1.getTime() + _1.getTimezoneOffset() * 60000);

Of course this will only work in the special case that the client has set the default timezone to UTC. If I could figure out how to get the timezone set by DateUtil.setDefaultDisplayTimezone(), I could apply the correct offset.

Until then... I was hoping that you might be able to tell me if I was on the right track.

--------------------------------

A brief explanation of the issue as I see it, and how I'm fixing it:

The fields for the DateTimeItem displays and saves the date in the correct timezone (that is whatever is set by DateUtil.setDefaultDisplayTimezone()). But the dateTime PICKER does not apply the default timezone but rather leaves it in the client's timezone. Thus functions on the javascript date object such as getDate() will at times return the EST date value when it should be returning the default timezone date value (e.g. 12 instead of 13). Since the underlying smartclient code seems to be using this function, the issue that I was explain occurs.

By applying the offset to manually change the chosen time to account for this, the function getDate() returns the right value. Luckily for me, it seems as though this "fix" does not affect any of the other functionality.

Anyway, any feedback would be appreciated...

Thanks.

[khkwang]

Okay, so the following changes made in the ICS_Forms.js file solved my issue. Since I'd rather not have to find some convoluted way to extend the original smartclient code, please let me know whether or not this is a legitimate bug on your end or if it was on my end I did something stupid with some settings.

Changes in bold.

function isc_DateChooser_setData(_1) {
    if (!isc.isA.Date(_1)) _1 = new Date();
    var _2 = "datetime";
    if (this.callingFormItem) {
        _2 = this.callingFormItem.type
    }
    var _3 = Date.getLogicalDateOnly(_1),
        _4 = Date.getLogicalTimeOnly(_1);
    this.year = _1.getFullYear();
    this.month = _1.getMonth();
    [b]var offset = (isc.Time.getUTCHoursDisplayOffset(_1) * 60 + isc.Time.getUTCMinutesDisplayOffset(_1) + _1.getTimezoneOffset()) * 60000;
    this.chosenDate = new Date(_1.getTime() + offset);[/b]
    var _5 = this.getTimeItem();
    if (_5) _5.setValue(_4);
    this.updateUI();
    this.dateGrid.setStartDate(this.chosenDate)
}

Thanks for your time.

[khkwang]

Thanks for the (lack of) help.

[khkwang]

I'm going to try one last time to get your attention on this matter.

THIS BUG IS REPRODUCIBLE IN YOUR SHOWCASE.

Steps to reproduce:
1) Go to http://www.smartclient.com/smartgwt/showcase/#form_controls_various
2) Open the JavaScript console, and run isc.Time.setDefaultDisplayTimezone("-0:00")
3) On the bottom of the showcase there is a field item "Relative Date" with a date picker. Click on this picker.
4) Select any date with the time 00:00 and apply.
5) Click the date picker again and notice the date has moved back by one day. Click apply.
6) Repeat step 5 until you go back to the land before time or ad nauseam.

Like I posted earlier, I've already patched this code locally but for your benefit and mine it would be nice to have an official fix.

Thank you.

[Isomorphic]

It's invalid to call setDefaultDisplayTimezone() when components have already been created, and this would cause the issue you're seeing.

Thanks for the attempted patch, but we will always need *first* is a way to reproduce the problem, with valid usage. Otherwise we are potentially looking at a patch for a non-problem, that will break something else.

[khkwang]

In my personal project I do in fact call setDefaultDisplayTimezone() before I create any components. It's actually one of the first things I even do.

I only gave the example of your showcase because that seemed like the only way to get your attention.

Now I concede that I could be doing something very stupid to cause this issue (as I have conceded from the very beginning). But it is also very possible that this is a real bug on your end.

I don't know what else to do for you. I've told you the issue, I've outlined the reproduction steps, I've given you a possible patch solution, demonstrated the issue in your own showcase code, and confirmed with you that I am not calling setDefaultDisplayTimezone() at any inappropriate times.

And your non-answer doesn't really leave me with any information. At least tell me that either (A) "We will look into it" or (B) "We will NOT look into it". At least then I'll know where you stand on this.

[Isomorphic]

We need a test case that reproduces the problem.

This is always what we need, as explained in the docs, the FAQ, an innumerable times on the forums, so there's really no mystery here.

You have only "outlined" the steps to reproduce the problem, presumably in your application, where several other customizations may be applied.

You then tried to show a reproducible case in the Showcase, but the approach was flawed.

So again just looking for a real test case.

[stonebranch1]

I too am having issues with Dates between the Client & Server when the client is in a different timezone. I have posted in more information in http://forums.smartclient.com/showthread.php?p=118231#post118231

This is becoming a real problem for me as I use Dates in several critical aspects of our application and they are showing up as different dates to the client depending on timezone settings.

[Isomorphic]

Again, this is very simple: we need a test case showing a bug. We receive a steady stream of false bug reports in the area of date and time handling because it is a very tricky area and people often get confused and miss-perceive correct behavior as flawed. So much time has been blown on investigations like that that we absolutely will not look into issues without a clear test case.

[khkwang]

package com.test.datetimepicker;

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.util.DateUtil;
import com.smartgwt.client.widgets.form.DynamicForm;
import com.smartgwt.client.widgets.form.fields.DateTimeItem;

public class TestDateTimePicker implements EntryPoint {

	public void onModuleLoad() {
		DateUtil.setDefaultDisplayTimezone("-00:00");

		DateTimeItem dti = new DateTimeItem();
		dti.setType("datetime");
		dti.setShowPickerTimeItem(true);

		DynamicForm form = new DynamicForm();
		form.setFields(dti);
		form.show();

	}
}

There. Please ensure first that your locale has a timezone that is BEHIND UTC, (such as EST).

Then run the sample code. Select any date with time of 00:00 and click apply. Now click the picker again and see that the date has changed to the one prior.

[Isomorphic]

Thanks, we'll check this out.

[khkwang]

Thank you, I appreciate you looking into it.