PDA

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



daviscabral
19 Nov 2007, 4:05 AM
Hi,

I have some datefields and when I click at any november day (year 2007), the field is filled with a date with one day before.

What can be?

Code:

new Ext.form.DateField({
fieldLabel: 'Data',
name: 'Atendente.DataAfastamento',
width: 120,
allowBlank: false
})

klaygomes
19 Nov 2007, 6:36 AM
daviscabral,
this problem was discuted before in this forum, but they never can simulate it.
[I]Este problema j

mystix
19 Nov 2007, 6:48 AM
are you using any of the l8n files?

(see this thread for more info: http://extjs.com/forum/showthread.php?t=14686)

klaygomes
19 Nov 2007, 7:26 AM
Mystix,
I think it is not the problem... Because we get the same on the docs exemples too.

Look at this topics:
http://extjs.com/forum/showthread.php?t=18461
http://extjs.com/forum/showthread.php?p=67018
http://extjs.com/forum/showthread.php?t=15247 (this is mine, witch i could not explain because my poor english)

I think the problem is on these lines of the DatePicker.js file:
(...)
523 var day = 86400000;
524 var d = (new Date(pm.getFullYear(), pm.getMonth(), prevStart)).clearTime();
525 var today = new Date().clearTime().getTime();
526 var sel = date.clearTime().getTime();
(...)
in especial with the function clearTime (where is it declared?)

mystix
19 Nov 2007, 8:13 AM
clearTime is declared in Date.js.

all it does is to clear any time values from a js Date object.

klaygomes
19 Nov 2007, 9:00 AM
Mystix,

I saw it...

I think it is a firefox bug, because if we execute alert(new Date()) we get something like Sun Oct 14 2007 14:49:34 GMT-0200, but when execute alert(new Date( (new Date()).setHours(0) )) we get Sat Oct 13 2007 23:50:30 GMT-0300 (Hora oficial do Brasil)...

i tryed to overhide this function (clearTime) to avoid it, but without sucess...

obs.: i set up my system date to 10/14/2007

H-care S.r.l.
11 Dec 2007, 5:46 AM
Mystix,

I saw it...

I think it is a firefox bug, because if we execute alert(new Date()) we get something like Sun Oct 14 2007 14:49:34 GMT-0200, but when execute alert(new Date( (new Date()).setHours(0) )) we get Sat Oct 13 2007 23:50:30 GMT-0300 (Hora oficial do Brasil)...

i tryed to overhide this function (clearTime) to avoid it, but without sucess...

obs.: i set up my system date to 10/14/2007

Well, I don't think it is a FF bug.
In the DatePicker code, Ext uses getTime function that, according with the mozilla javascript documentation, "returns the numeric value corresponding to the time for the specified date according to universal time". So DatePicker should use UTC time everywhere in the code.

Here it is a patch that could solve the problem (there's still an issue with the selected day, but works in FF 2, IE 6 and Safari 3):

Index:
ext-all-debug.js


---
ext-all-debug.js (revision 14723)
+++
ext-all-debug.js (working copy)
@@ -27486,7 +27486,7 @@


var day = 86400000;
- var d = (new Date(pm.getFullYear(), pm.getMonth(), prevStart)).clearTime();
+ var d = (new Date(pm.getUTCFullYear(), pm.getUTCMonth(), prevStart)).clearTime();
var today = new Date().clearTime().getTime();
var sel = date.clearTime().getTime();
var min = this.minDate ? this.minDate.clearTime() : Number.NEGATIVE_INFINITY;
@@ -27540,7 +27540,7 @@
var i = 0;
for(; i < startingPos; i++) {
textEls[i].innerHTML = (++prevStart);
- d.setDate(d.getDate()+1);
+ d.setUTCDate(d.getUTCDate()+1);
cells[i].className = "x-date-prevday";
setCellClass(this, cells[i]);
}
@@ -27547,7 +27547,7 @@
for(; i < days; i++){
intDay = i - startingPos + 1;
textEls[i].innerHTML = (intDay);
- d.setDate(d.getDate()+1);
+ d.setUTCDate(d.getUTCDate()+1);
cells[i].className = "x-date-active";
setCellClass(this, cells[i]);
}
@@ -27554,7 +27554,7 @@
var extraDays = 0;
for(; i < 42; i++) {
textEls[i].innerHTML = (++extraDays);
- d.setDate(d.getDate()+1);
+ d.setUTCDate(d.getUTCDate()+1);
cells[i].className = "x-date-nextday";
setCellClass(this, cells[i]);
}

H-care S.r.l.
19 Dec 2007, 2:35 AM
Can anybody validate this patch? If this patch is right, it sould be included into the trunk.

Regards,
Pierpaolo

Coolite
25 Jan 2008, 10:19 AM
Hi Pierpaolo,

I don't think the proposed patch of converting the values to UTC is the answer.

I'm guessing you're pulling the date from a database, so I have a hunch the root of the problem has something to do with the timezone of the date in the database, not matching the timezone of the browser.

For example, the date in the database might be stored as UTC, but when rendered to the browser, the DateField/DatePicker is using the browsers local timezone settings.

Once the date is pulled into the DateField/DatePicker, the .clearTime() function comes in for the final kill. For example if the timezone of the date in the database is even one hour different (less) than the browsers timezone there's going to be trouble.

A date value stored in the database as 5-Jun-2008 @ 00:00 UTC, then sent to browser (-1 hour timezone) may be converted by the browser to 4-Jun-2008 @ 23:00. Once passed through .clearTime(), the date will be changed to 4-Jun-2008 @ 00:00. Hence, the date being "off-by-one".

If your database is storing date values as UTC, and your browser is set to Pacific Standard Time (PST -800), 5-Jun-2008 @ 00:00 UTC, may result in a date of 4-Jun-2008 @ 16:00 being rendered in the browser.

To verify, I'd need someone to post a full sample with the JSON/config, confirmation of browser's local/timezone and the date value coming stored in the server.

There might be answer with converting the dates to UTC, although confusion is sure to happen because users are expecting the DateField value to be relative to their machine.

I could be wrong, but I'm certainly available to step through the problem with anyone willing to troubleshoot.

Hope this helps.

H-care S.r.l.
29 Jan 2008, 7:07 AM
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.
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.

Since I have to deploy an Ext application for production, I need to deploy a working one. This patch is probably a bad workaround of the problem, but it works. If there is a better solution coming from ext developers, then I'll be happy for that...in the meanwhile I'll patch Datepicker.js every svn update.

Regards,
Pierpaolo

Coolite
29 Jan 2008, 7:23 AM
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
29 Jan 2008, 7:39 AM
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
29 Jan 2008, 7:53 AM
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
29 Jan 2008, 8:24 AM
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 8-|)

H-care S.r.l.
31 Jan 2008, 12:41 AM
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
19 May 2008, 11:44 AM
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.
20 May 2008, 1:14 AM
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
13 Oct 2008, 1:05 PM
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 8-|)

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
20 Oct 2008, 12:29 PM
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
28 Oct 2008, 10:24 AM
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 !

lombras
1 Dec 2008, 5:00 AM
Hello!!

where i need add this code? i'm using ext-2.2!



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

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

this.setMinutes(0);
this.setSeconds(0);
this.setMilliseconds(0);
return this;
};

efreitasrj
1 Dec 2008, 6:00 AM
Lombras,

This is an override to Ext's functions, so you should add this code to your project's javascript files, after the Ext library has been loaded. There's no need to modify the Ext library.

mystix
12 Mar 2009, 6:25 PM
[ follow-up ]
here's a list of changes i'm proposing for Ext 2.2.1's DatePicker / Date which should do the trick for 1.x too as the DatePicker / Date codes haven't changed much since 1.x:
302310

turns out it required a combination of both UTC format hour / minutes / seconds / milliseconds, a tiny change to clearTime()'s internals, and an additional check for DST to resolve the matter (see link for more details).

the reason why most of us in non-DST / english locales can't reproduce the problem on WinXP is that the DST timezones aren't automatically updated (requires a registry patch from m$ (http://support.microsoft.com/kb/914387)).

carmelchas
20 Sep 2011, 10:42 AM
I had the same problem. It turns out that if the date value in an Ext.data.Model is timezone unaware, then Firefox 6.0.2 converts the time to the client's timezone when loading data. I am in CST and therefore some dates appear to be the day before.

Picking and submitting dates worked fine. However, when the data is reloaded from the database the value is timezone unaware (e.g. '1972-10-29'). Instead of assuming UTC, in Firefox 6.0.2, the date is parsed and converted to the client timezone.

I was able to fix the problem by changing my Ext.data.Model configuration
FROM: {name: 'dob', type: 'date'},TO: {name: 'dob'},