DateField: I picked up 11/29/2007, but field receive 28/11/2007

[Coolite]

Hi Pierpaolo,

Thanks for the update. I guess I need to do a little more research/work on the problem.

Can you post what your regional machine/browser settings are? What is your current timezone offset? Are you observing Daylight Saving Time. I have another hunch on what the root of the problem might be, but need to reproduce the issue on a local machine.

[mystix]

Well, maybe I'm wrong, but I don't think Ext library should be aware of how dates are saved into the database, 'cause if I want to save dates as strings, then Ext should perform automatic conversions too.

what do you mean?

I think here we have a problem into the view layer, into the component. If the code of the component use a UTC method and then, after few lines, use a non UTC method, then there is a problem. And I can see this problem here on my browsers (IE, FF and Safari) every time I try to choose a date that is in a different time zone from my current one (i.e. if I'm in CET and I choose a CEST date and vice versa), and not while reading a date from the database. I simply click on a date in the picker, and I get another one in the text field.

could you provide a simple test case (browser agnostic please) to demonstrate this problem, and a clearer explanation of the scenario?
why would you pick, say, a CEST date if you're sitting in the CET timezone?
how would you even do that in code?

[Coolite]

could you provide a simple test case (browser agnostic please) to demonstrate this problem, and a clearer explanation of the scenario? why would you pick, say, a CEST date if you're sitting in the CET timezone? how would you even do that in code?

I think he's referring to picking a date that falls outside of the current Daylight Saving Time (Summer Time). CEST is Central European Summer Time. CET is Central European Time. Same as picking a date in PST if you're currently in PDT.

I'm 80% confident the problem is connected to DST. I just haven't had a chance to work it all the way through.

[mystix]

I'm 80% confident the problem is connected to DST. I just haven't had a chance to work it all the way through.

hmm... sounds possible. i actually got a video from one of our Brazillian Ext users demonstrating this problem, but not being able to consistently reproduce the problem in code makes this bug a tough one to nail.

if you have a test case / start working on this be sure to update this thread. i'll chip in when i can (got a ton of things on hand )

[H-care S.r.l.]

Sorry for my delay.
Coolite is right about the problem...and I'm more optimistic than him: I think the problem is 100% connected to the DST. Unfortunately the code of the DatePicker is complex, and at this time I can't produce any better solution than the previously attached patch. Sorry for that.
I'll try during next week end to get out something more solid and maybe an example of code to reproduce the bug "everywhere".

Thank you for paying attention to this problem.

Regards,
Pierpaolo

[Nthalk]

The problem that you are experiencing seems to be the same as my current one.

When I save a field with the DateField/DatePicker, the ajax post has a mostly correct date:

datetest: Thu+May+22+2008+00:00:00+GMT-0700+(PDT) 

When I replace the "+"s with " "'s, and use php's strtotime function on it and then use the date function, like so:

var_dump(date('Y-m-d',strtotime(str_replace('+',' ',"Thu+May+22+2008+00:00:00+GMT-0700+(PDT)")))); 

I get a date that is one day behind:

string(10) "2008-05-21" 

However, if I remove the timezone info and use this date:

$date = "Thu+May+22+2008+00:00:00"
echo date('Y-m-d',strtotime(str_replace('+',' ',$date))); # Prints "2008-05-22" 

I believe that this is happening because my PHP timezone is different than my browser's, and when strtotime parses a different timezone timestamp, it shifts the parsed value to it's own timezone, making it incorrect if someone really really just wanted the 22nd of May.

The problem may not lay within extjs, but in the difference of configured timezones from your browser to your backend. It would be nice if ext let us specify our own date output like it does our input.

I put in an ugly hack like so:

$date = reset(explode('00:00:00',$date)); # Because I don't care about hours or seconds, just days. (extjs hack also)
$time = strtotime($date); 

[H-care S.r.l.]

The problem may not lay within extjs, but in the difference of configured timezones from your browser to your backend. It would be nice if ext let us specify our own date output like it does our input.

No, my problem persist also without a backend: I can replicate it using a simple html/js page using an ext calendar control.

[eliezerreis]

hmm... sounds possible. i actually got a video from one of our Brazillian Ext users demonstrating this problem, but not being able to consistently reproduce the problem in code makes this bug a tough one to nail.

if you have a test case / start working on this be sure to update this thread. i'll chip in when i can (got a ton of things on hand )

Yes, the problem is with DST and I do the code below that resolve the problem for now.

Ext.form.DateField.prototype.menuListeners.select = function(m, d) {
	this.setValue(d);                 
	this.fireEvent('dateselect');
}
Date.prototype.clearTime = function(clone){
    if(clone){
        return this.clone().clearTime();
    }
    this.setHours(0);
    this.setMinutes(0);
    this.setSeconds(0);
    this.setMilliseconds(0);
    this.setTime(this.getTime()+(3600000));

    return this;
};

I hope that solve some problems. CYA

[vinibdr]

Hi everybody,

I was facing the same problems with datepicker in firefox and IE. When i reconfigured properly the OS timezone, i discovered that it was not a ext js bug.

I am using an NTP server to synchronize my computer's time and
i set it to UTC with GMT -3. Before i had this misconfigured, after i fixed it, the problem with datepicker disappeared.

Thanks for Ext team orientations and your very good tools developed.

[efreitasrj]

Yes, the problem is with DST and I do the code below that resolve the problem for now.

I hope that solve some problems. CYA

Your code works for days AFTER the DST is in effect. Let's say the DST starts on October 19th. If you try to select the 20th day, everything works fine after the fix. But if you try to select 19, it won't work because there isn't a 10/19/2008 0:00:00. That means the fix can't set hours to 0 in this case. The fix below should correct this minor inconsistence.

Date.prototype.clearTime = function(clone){
     if(clone){
    	return this.clone().clearTime();
    }

    if(this.getHours() == 23){
    	this.setTime(this.getTime()+(3600000));
    }else{
    	this.setHours(0);
    }
    
    this.setMinutes(0);
    this.setSeconds(0);
    this.setMilliseconds(0);
    return this;
};

None of these fixes are very good though, as every date with a time component of 23 hours will be altered to the next day. The patch Pierpaolo sent seems to make a lot of sense !!! Could some of the Ext developers shed a light on this matter ?

This probably is a difficult to simulate scenario because the DatePicker is only affected on the month that the DST kicks in. In our brazilian scenario, where this year our DST starts on the 19th October, the ONLY affected dates are from 20th October to the last date shown on the date picker page. If you select one of the November dates from the OCTOBER calendar page, it WILL be affected, whilst if you change the month to November, nothing wrong will happen.

Please, consider Pierpaolo's suggestion of using UTC dates throughout the component, as there's some sort of strange behaviour happening with Javascript and Windows machines with the "Observe Daylight Saving Time" option flagged on.

By the way, this problem also affects Ext 2.2 !