PDA

View Full Version : [CLOSED-34] [3.x/2.x] Ext.form.TimeField and Daylight Saving switch



christocracy
8 Mar 2008, 10:01 PM
Not sure if this is an ext bug yet. this is super-wonky.

when daylight-saving time kicked in, my Ext.form.TimeField are stuck in an infinate loop at initComponent.

Browser is giving me the "A script is taking longer than usual to execute" line. I tried restarting my machine, but it didn't fix it.

I'm on Ubuntu 7.10 and I can only confirm this on FF 2.0.0.12

I'm cycling through the while loop with debugger (see code, where I've noted)

min: Sun Mar 09 2008 01:30:00 GMT-0500 (EST)
max: Sun Mar 09 2008 23:59:00 GMT-0400 (EDT)

min time cycles infinitely like so: |1:00, 1:15, 1:30, 1:45, 1:00, 1:15, 1:30,1:45...|

I'll play with this a bit more.



initComponent : function(){
Ext.form.TimeField.superclass.initComponent.call(this);

if(typeof this.minValue == "string"){
this.minValue = this.parseDate(this.minValue);
}
if(typeof this.maxValue == "string"){
this.maxValue = this.parseDate(this.maxValue);
}

if(!this.store){
var min = this.parseDate(this.minValue);
if(!min){
min = new Date().clearTime();
}
var max = this.parseDate(this.maxValue);
if(!max){
max = new Date().clearTime().add('mi', (24 * 60) - 1);
}
var times = [];

while(min <= max){ // <---------------------------- Infinate loop here
times.push([min.dateFormat(this.format)]);
min = min.add('mi', this.increment);
}

this.store = new Ext.data.SimpleStore({
fields: ['text'],
data : times
});
this.displayField = 'text';
}
},

christocracy
8 Mar 2008, 11:27 PM
following is incrementing time by 15min (just as TimeField does to load its store). look what happens when it hits 1:45 -- it jumps *back* to 1:00. shouldn't it have jumped *ahead* to 3:00, since this is daylight-saving?

If you have an Ext.form.TimeField with default minValue / maxValue in your code, your app might be toast until Mar 10 rolls around.



>>> m = new Date().clearTime();
Sun Mar 09 2008 00:00:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 00:15:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 00:30:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 00:45:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:00:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:15:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:30:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:45:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:00:00 GMT-0500 (EST)
>>> m = m.add('mi', 15);
Sun Mar 09 2008 01:15:00 GMT-0500 (EST)

FXetc
9 Mar 2008, 12:09 AM
I'm getting the same thing! Using Firefox 2.0.0.12. As soon as it hit midnight my application would hang EVERY browser it was loaded to. (I'm on Windows Vista) I'm lucky I could temporarily remove the TimeField without losing major functionality. :s

rogerr
9 Mar 2008, 9:37 AM
it gets stuck in an infanite loop when trying to increment from 1:45 to 2am, but daylight savings causes it to go back to 1:00am instead.

Here is a very quick fix you can add to your page(s) to at least stop the runaway looping, until a more correct fix is available from the good people at Ext.


Ext.override(Ext.form.TimeField, {

// cap the number of items in the drop down menu
maxMenuItems: 100,

// private
initComponent : function(){
Ext.form.TimeField.superclass.initComponent.call(this);

if(typeof this.minValue == "string"){
this.minValue = this.parseDate(this.minValue);
}
if(typeof this.maxValue == "string"){
this.maxValue = this.parseDate(this.maxValue);
}

if(!this.store){
var min = this.parseDate(this.minValue);
if(!min){
min = new Date().clearTime();
}
var max = this.parseDate(this.maxValue);
if(!max){
max = new Date().clearTime().add('mi', (24 * 60) - 1);
}
var times = [];
var maxItems = this.maxMenuItems;
while(min <= max && --maxItems >= 0){
times.push([min.dateFormat(this.format)]);
min = min.add('mi', this.increment);
}
this.store = new Ext.data.SimpleStore({
fields: ['text'],
data : times
});
this.displayField = 'text';
}
}
});

skyout
9 Mar 2008, 4:32 PM
Thanks for the quick fix.

thoriann
29 Mar 2008, 5:06 PM
Just hit the same bug. I worked around it (before finding this thread) by adding:


new Ext.form.TimeField({
minValue: Date.parseDate('01/10/2007 00:00:00', 'd/m/Y H:i:s'),
maxValue: Date.parseDate('01/10/2007 23:59:59', 'd/m/Y H:i:s')
})

in the TimeField configuration. I.e. do the store building using some random date. Then, make sure you discard the date when using the value.

IMHO, this bug is serious, since it's causing the browser to hang while viewing the page. For a full day, once per year.

P.S. As this was my first post to the forum (sorry that was on a bug), I wish to congratulate the Ext team on the outstanding library. Thank you!

Sliver
30 Mar 2008, 1:25 AM
I just hit the same bug with the French daylight saving switch !
Thanks for the little fix, it avoids 2 day per year of total extjs-timefield-black-out !

May Jack or anyone else competent include this fix to the next version of Ext ?;)

brian.moeskau
30 Mar 2008, 1:35 AM
Thanks, we'll get it fixed soon.

thoriann
30 Mar 2008, 2:07 AM
Hi, just trying to help here. Another possible solution would be:



Ext.override(Ext.form.TimeField, {
initComponent : function(){
Ext.form.TimeField.superclass.initComponent.call(this);

if(typeof this.minValue == "string"){
this.minValue = this.parseDate(this.minValue);
}
if(typeof this.maxValue == "string"){
this.maxValue = this.parseDate(this.maxValue);
}

if(!this.store){
var min = this.parseDate(this.minValue);
if(!min){
min = new Date().clearTime();
}
var max = this.parseDate(this.maxValue);
if(!max){
max = new Date().clearTime().add('mi', (24 * 60) - 1);
}
var times = [];
while(min <= max){
times.push([min.dateFormat(this.format)]);
var next_min = min.add('mi', this.increment);
if (next_min < min) {
// DST change detected. Trying to go over it.
next_min = next_min.add("mi", 120);
}
min = next_min;
}
this.store = new Ext.data.SimpleStore({
fields: ['text'],
data : times
});
this.displayField = 'text';
}
}
});


With this, the combo will not display the 2:00 hour, which is actually correct. It will not work if the DST is larger than 1 hour (does this ever happen?).

brian.moeskau
13 May 2008, 12:19 AM
The TimeField is not and cannot be DST-aware. Coding for DST is tricky business since it is locale-specific and year-specific. If your app requires true DST handling, it's up to you to provide the appropriate validation that checks validity of times given the DST requirements of your application (I've done this myself in the past using a huge iCal-format file of DST data). Of course the looping bug must be fixed, but the best we can really do is always generate a consistent set of time values, even on DST dates.

So the solution I came up with is simply to always generate times based off of a static, safe date rather than relying on the current user local date. That way you'll be assured that times will always be generated consistently. Here's the patch (this is already in SVN):



Ext.override(Ext.form.TimeField, {

// private - This is the date to use when generating time values in the absence of either minValue
// or maxValue. Using the current date causes DST issues on DST boundary dates, so this is an
// arbitrary "safe" date that can be any date aside from DST boundary dates.
initDate: '1/1/2008',

initComponent : function(){
Ext.form.TimeField.superclass.initComponent.call(this);

if(typeof this.minValue == "string"){
this.minValue = this.parseDate(this.minValue);
}
if(typeof this.maxValue == "string"){
this.maxValue = this.parseDate(this.maxValue);
}

if(!this.store){
var min = this.parseDate(this.minValue);
if(!min){
min = new Date(this.initDate).clearTime();
}
var max = this.parseDate(this.maxValue);
if(!max){
max = new Date(this.initDate).clearTime().add('mi', (24 * 60) - 1);
}
var times = [];
while(min <= max){
times.push([min.dateFormat(this.format)]);
min = min.add('mi', this.increment);
}
this.store = new Ext.data.SimpleStore({
fields: ['text'],
data : times
});
this.displayField = 'text';
}
}
});

siebertm
29 Mar 2009, 1:37 AM
Please note that this bug ist NOT fixed and it makes every application stop on DST switch days...
the application just has to use Ext.form.TimeField with maxValue and minValue as strings.
since this is a known bug that appears EVERY spring, why dont you fix it? are we, the paying users not worth it?

i'm pretty pissed because we have a calendaring application that just DOES NOT WORK today.

what are you gonna do?

evant
29 Mar 2009, 2:09 AM
What do you mean isn't fixed? Can you post a test case that uses the latest code we can use to demonstrate the problem?

siebertm
29 Mar 2009, 2:15 AM
the test case is the following:

use a normal ext 2.2
prepare a panel with a timefield.

thats it. endless loop ftw. change the date on your computer and it works again.
note that you'll have to set a time zone that uses dst (e.g. cet / cest).

i now use thoriann's solution which works (at least does not do an endless loop)

mystix
29 Mar 2009, 4:19 AM
the test case is the following:

use a normal ext 2.2
prepare a panel with a timefield.

thats it. endless loop ftw. change the date on your computer and it works again.
note that you'll have to set a time zone that uses dst (e.g. cet / cest).

i now use thoriann's solution which works (at least does not do an endless loop)

you'll also need to state your timezone and your windows build.

siebertm
29 Mar 2009, 4:20 AM
you'll also need to state your timezone and your windows build.

my timezone is cest and my windows build is a mac.

mystix
29 Mar 2009, 4:22 AM
my timezone is cest and my windows build is a mac.

could you be a little more specific please? CEST = GMT+0200?
and fwiw, mac != windows.

are you running the example in FF3 on a mac?

siebertm
29 Mar 2009, 4:27 AM
could you be a little more specific please? CEST = GMT+0200?
and fwiw, mac != windows.

are you running the example in FF3 on a mac?

okay. my time zone is cest=utc+2 (but until today 2am it was utc+1)

the problem is neither browser nor os specific since i tested it on various browser / os combinations. it is really a bug in the extjs code. the provided solution works as i stated above but i think its a shame that i as a paying user have to cram through the forums for patches for known bugs in ext.

mystix
29 Mar 2009, 4:41 AM
okay. my time zone is cest=utc+2 (but until today 2am it was utc+1)

the problem is neither browser nor os specific since i tested it on various browser / os combinations. it is really a bug in the extjs code. the provided solution works as i stated above but i think its a shame that i as a paying user have to cram through the forums for patches for known bugs in ext.

could you post your TimeField code?
what initDate, maxValue and minValue did you use?

brian.moeskau
29 Mar 2009, 5:35 AM
Are you sure you have the latest version? Have you tried the override from my post (http://extjs.com/forum/showthread.php?p=167193#post167193)? Note that that fix specifically avoids using a locale or timezone-specific date to generate times. Or are you seeing a different issue than that described originally?

mystix
29 Mar 2009, 6:56 AM
alright, here's a simplified test case @siebertm should've posted in the first place /:)


new Ext.form.TimeField({
minValue: '1:00am',
maxValue: '3:00am',
renderTo: document.body
});

this test fails with the 2.2.1 codebase.


test code prerequisites for winxp users:

on a WinXP SP3 machine, go to Control Panel > Date and Time > Time Zone and select GMT+01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. make sure the "Automatically adjust clock for daylight saving changes" checkbox is ticked, and that the winxp timezone db has been updated (http://support.microsoft.com/kb/914387)
set the system date to 29th March 2009.

mystix
29 Mar 2009, 7:27 AM
@siebertm, include this override immediately after ext-all.js:


Ext.override(Ext.form.TimeField, {
// *** no longer required
// by @mystix -- http://extjs.com/forum/showthread.php?p=337620#post337620
//*** i.e. select a value from the Store
beforeBlur: Ext.form.TimeField.superclass.beforeBlur,

initDateFormat: 'j/n/Y',

parseDate: function(value) {
if (!value || Ext.isDate(value)) {
return value;
}

var id = this.initDate + ' ',
idf = this.initDateFormat + ' ',
v = Date.parseDate(id + value, idf + this.format), // handle DST
af = this.altFormats;

if (!v && af) {
if (!this.altFormatsArray) {
this.altFormatsArray = af.split("|");
}
for (var i = 0, afa = this.altFormatsArray, len = afa.length; i < len && !v; i++) {
v = Date.parseDate(id + value, idf + afa[i]);
}
}

return v;
}
});

if (parseFloat(Ext.version) < 3) { // for Ext 2.x
Ext.override(Ext.form.TimeField, {
initComponent: function() {
// since minValue / maxValue are only used to setup the TimeField's store, it should be
// safe to ignore them (i.e. avoid parsing them for validity) if a store has already been defined

if (!this.store) {
// combine vars to save code
var dt = Date.parseDate(this.initDate, this.initDateFormat).clearTime(),
min = this.minValue = this.parseDate(this.minValue) || dt,
max = this.maxValue = this.parseDate(this.maxValue) || dt.add('mi', (24 * 60) - 1),
times = [];

while (min <= max) {
times.push(min.dateFormat(this.format));
min = min.add('mi', this.increment);
}
this.store = times;
}
Ext.form.TimeField.superclass.initComponent.call(this);
}
});
}


tested and working with the test case i posted.

mono blaine
29 Mar 2009, 10:24 AM
oh my god this is the most horrible bug i have ever seen. it costed my whole day!

mystix
29 Mar 2009, 10:31 AM
oh my god this is the most horrible bug i have ever seen. it costed my whole day!

does the fix i posted work for you?

mono blaine
29 Mar 2009, 10:34 AM
nope. it gives an error:

min is not defined
while(min <= max){
.....

mystix
29 Mar 2009, 10:36 AM
nope. it gives an error:

min is not defined
while(min <= max){
.....

errrr i edited after you posted apparently. look at the code again.

mono blaine
29 Mar 2009, 10:39 AM
wow wow wait, sorry. it works, actually. no more infinite loops. thanks! i think you edited your post after i copied it. that was the reason of the error.

mystix
29 Mar 2009, 10:47 AM
great. :)

(i've reopened this bug report in the meantime)

mono blaine
29 Mar 2009, 11:07 AM
by the way i'm using ext 2.0.1, in case you should know.

mystix
9 Jun 2009, 9:57 AM
[ friendly bump ]
note: this also affects the 3.x branch.

also updated post #21 for 2.x/3.x SVN.

mystix
24 Jun 2009, 7:55 PM
[ moved to 3.x Bugs from 2.x Bugs ]

and

[ a bump for posterity ]

in light of this 3.x bug report:
72326

Jamie Avins
19 Feb 2010, 9:08 AM
This is now in the 3.2.x branch in svn.

gwcoffey
14 Mar 2010, 2:55 PM
This is a TERRIBLE CRASHING BUG and you sat on it for a year, then put the fix in the 3.2.x branch when it was TOTALLY CLEAR it was going to hit your real customers in just one month's time.

Really?! This wasn't worth a patch for the shipping version and a note somewhere?!

You know, something like "Warning US customers, all your apps will die on March 14th. You might want to apply this patch." I lost half my Sunday because I happen to be in Phoenix, where we don't change times, and my customer is in Michigan where they do. So I can't reproduce the problem here, and it took me ages to figure out why it was happening on his browsers. I had to debug your lousy code over VNC to find the real problem, only to discover it's a bug you've known about for 12 months.

I'm an exceptionally patient person, but this is just plain stupid. You have failed.

jay@moduscreate.com
14 Mar 2010, 5:16 PM
will there be a patch for the 2.x customers?

Mjollnir26
19 Mar 2010, 8:14 AM
Not sure if this has been mentioned before in any of the VARIOUS Datepicker/Field/Menu whatever bug threads but you can crash FF3.6 easily just by putting the following in the (any) Toolbar(config):



{
width:200,
id: 'df-1',
xtype: 'datepicker',
//value:new Date(page.timeFrom)
//dont ever do this with an invalid /undefined value or ff is dead!
value:new Date() //works
}


As a side note, there are really lots of threads around this board all about Date.* issues. Are all thoses cases fixed in the 3.2 branch??
Just two of various Threads:
http://www.extjs.com/forum/showthread.php?t=62250
http://www.extjs.com/forum/showthread.php?t=62250

mystix
19 Mar 2010, 8:19 AM
Not sure if this has been mentioned before in any of the VARIOUS Datepicker/Field/Menu whatever bug threads but you can crash FF3.6 easily just by putting the following in the (any) Toolbar(config):

{
width:200,
id: 'df-1',
xtype: 'datepicker',
//value:new Date(page.timeFrom)
//dont ever do this with an invalid /undefined value or ff is dead!
value:new Date()
}

that shouldn't be possible in 3.2-beta (assuming your client machine's windoze timezone database has been updated, and your DateField/DatePicker has been correctly configured for your locale).

please post a test case (in a new thread).

Jamie Avins
19 Mar 2010, 9:18 AM
Actually there was a bug in the beta build that was fixed Mystix. But it's all good now /:)

mystix
19 Mar 2010, 9:47 AM
Actually there was a bug in the beta build that was fixed Mystix. But it's all good now /:)

whoops.

i scanned through the past 50 odd revisions before posting, but it looks like i've missed it. :">

[edit]
i see it now:


safeParse : function(value, format) {
if (/[gGhH]/.test(format.replace(/(\\.)/g, ''))) {
// if parse format contains hour information, no DST adjustment is necessary
return Date.parseDate(value, format);
} else {
// set time to 12 noon, then clear the time
var parsedDate = Date.parseDate(value + ' ' + this.initTime, format + ' ' + this.initTimeFormat);

if (parsedDate) return parsedDate.clearTime();
}
}

my bad.

Mjollnir26
21 Mar 2010, 3:27 PM
Hmmm... pretty sure i was using 3.1.1 when that came up, but i recently switched companies and was given a rather old c2d with windows xp on it... don't even know which patchlevel that OS has currently.

mystix
21 Mar 2010, 5:52 PM
Hmmm... pretty sure i was using 3.1.1 when that came up, but i recently switched companies and was given a rather old c2d with windows xp on it... don't even know which patchlevel that OS has currently.

ignore my comment
-- there was a bug in the safeParse() method which blind me failed to see. my bad (refer to the code in red in my previous post)

it's fixed in SVN now though.
you could grab that, or apply an override using the code in my previous post, or simply wait for the 3.2RC release.

brian.moeskau
1 Apr 2010, 9:31 AM
I just ran into this safeParse issue -- I was about to get a little worried... :) Thanks for the override, works fine now.

bone
16 Apr 2010, 12:18 AM
Just a quick note:

( new Date(Date.parse("")) ).clearTime()

fails in 3.2

i DO understand that its stupid to try and create a Date based of NaN, but its equally stupid to for-loop an invalid Date