I really, really wouldn't recommend altering or replacing WebKit... it's an important part of OS X, and unless you really know what you're doing, you could end up breaking a lot of stuff!

It's also not necessary for the changes António has been making. There is a problem with WebKit in Dashboard, but it looks like he's managed to work around it.

Instead, the idea is to edit the code in the Flight Tracker widget itself. It's also a very good idea to take a copy of the widget and alter that instead. Saying that, even then it's not something I'd consider a job for a beginner. I would read up on developing widgets before you attempt this.

Right now, the unaltered Flight Tracker seems to be working properly for me, so I can't really check António's changes. I'm using Leopard (10.5.1) and am currently in GMT. I only seemed to have trouble when we were in British Summer Time.

To use your modifications I looked for and found this WebKit file on my system (OS X.10.4.11 (PowerPC)). However I couldn't open it or write the code you mentioned above in it. (Normally I just use this MAC and not hack within it's entrails....) Any hint for beginners how to open this WebKit file? Is there a danger if I mess it up?
Be sure ANY comment would be highly appreciated!
Anjin, frequent flyer, Lisboa

The problem is that the setUTCHours(), setUTCMinutes() and setUTCSeconds() are buggy in the current javascript engine present in Dashboard (actually, WebKit v.419.2.1). Each one of this methods adds an extra hour if you are located in Portugal, Great Britain or Ireland. As each on of these methods are called in function createDateFromServerString(), we usually get a wrong 3 hours offset from our local clock.

I solved these issue, adding the following patch in createDateFromServerString() function:

//date.setUTCHours(hour); // setUTCHours() is buggy in WebKit version 419.2.1
//date.setUTCMinutes(min);
//date.setUTCSeconds(sec);
date.setHours(hour-date.getTimezoneOffset()/60, min, sec); // Here is the deal!

I commented out the three original lines, and added the last line to do the right thing!

I did another modification, as of personal taste: I just want to know the departure/landing times according to my own clock, and not according to the place where the plane takes off/lands. So I went to formatDateForDisplay() and did the following modification:

//var date = new Date();
//var tzOffset = dateInfo.tzOffset - date.getTimezoneOffset()*60000;
//date.setTime(dateInfo.date.getTime() - tzOffset);
//if (date != null) {
if (dateInfo.date != null) {
//var timeStr = date.toLocaleTimeString("short");
var timeStr = dateInfo.date.toLocaleTimeString("short"); // This line added!
if (timeStr != "Invalid Date") {
retVal = timeStr;
}
}

It is working, now, on several timezones, and you are free to test it out!

Cheers!

Nevertheless, this widget works perfectly if you use any timezone (for instance, Central Europe, any of America's timezone) which is not "over" the GMT meridian; if you are "over" GMT, then comes those 3 extra hours.

My next step will be to inject some parts of FlightTracker code in the test widget (initially HelloWorld, now WorkHorse), and check if the date is being properly processed by the javascript engine used by Dashboard.

But this will have to wait for more free time... :(

Anyway, good job investigating this one, António... what do you think is the actual piece of code that's broken?

From what I can tell, createDateFromServerString() returns a valid date object, along with tzOffset and dayOffset. I've played around with my timezone, date (forcing daylight savings), and some input strings, and it seems to give the correct results, when the date object returned is fed through .toUTCString().

So, if that date object is correct, then it must be the conversion to local time (ie. toLocaleTimeString), OR tzOffset returned by createDateFromServerString().

If that's the case, then by taking the date object (ie. dateInfo.date) and a fresh "now" date (ie. new Date()), and subtracting one from the other:

var dateInfo = createDateFromServerString(foo);
var now = new Date();
var diff = now.getTime() - dateInfo.date.getTime();

you should then have a correct number of milliseconds, so you could say "in 15 minutes" or "6 hours ago" rather than a misleading and potentially bogus "local" time. Alternatively, you could write your own "toLocaleTimeString" that works.

All that's assuming that dateInfo.date is correct, though... ie. dateInfo.date.getTime() returns the correct number of milliseconds since midnight of January 1, 1970 UT/UTC/GMT/+0/Z, rather than using some timezone local to the browser or the flight in question.

Have you got any definite test cases to say that it's not correct?

Unfortunately, I'm swamped at the moment, so I can't spend any significant time on this :(

Incidentally, I just checked and the bug I filed with Apple was marked as a duplicate of #4617358, and closed, so I can't track it.

The same javascript code writes the following:

ON SAFARI 3.0.4 (523.12):
Your WebKit version number is 523.12 and is not a nightly build.

ON DASHBOARD:
Your WebKit version number is 419.2.1 and is not a nightly build.

So, that's why I was getting different results with the same code!!! The actual version of WebKit deals properly with LAT 0º time zones, but the one used by Dashboard does not.

NEXT QUESTION: How can I update Dashboard's WebKit?

The createDateFromServerString() function should be working correctly, and there is only malfunction if you are living near GMT... winter time or summer time.

I tried the createDateFromServerString() code in a html page, run it on firefox and safari, and worked fine. On this widget, it adds 3 hours if you are on GMT, GMT+1 (summer), WET (Western Europe Time) or WEST (summer).
HOW MANY JAVASCRIPT ENGINES ARE RUNNING IN MAC OSX???!!

As I usually guide myself on Portuguese time, even when I am abroad, I tweaked the FlightTracker.js the following way...

In function formatDateForDisplay():

//date.setTime(dateInfo.date.getTime() - tzOffset); // ORIGINAL CODE
date.setTime(dateInfo.date.getTime() - 3*3600000); // MY CODE

I want to know the landing/departure times according to my clock, and not according to (other people's) local times, so I took off the 'tzOffset', as it would simply put back the time difference. Remember that the dateInfo already has the time in UTC and the .toLocaleTimeString method outputs the time already according to your local clock.
Then, I just ripped the extra 3 hours. It is working fine.

if (!isNaN(tzhour) && !isNaN(tzmin)) {
tzOffsetMS = tzhour * 3600 * 1000 + tzmin*60*1000;
if (tzsign == "+")
tzOffsetMS *= -1;
}

should handle the 'Z' situation...

When a flight has a departure/landing date in UTC (Zulu time), the string in the xml file is as follows (flights departing from Oporto - OPO):

2007-12-10T15:40:50Z
2007-12-10T13:35:00Z
2007-12-10T16:10:00Z

Just take a look of a landing time in Palma de Maiorca:

2007-12-10T18:55:00+01:00

Taking a look at the code, it is not prepared to handle the 'Z'., But still, I don't know what string is really processed by the createDateFromServerString() function.

Nevertheless, I don't understand why it takes any time and sums 3. It seems to me that the author wanted to show times in 'client-computer-time', not in local departure/landing time.

I llve in Portugal and my time zone is (I believe) considered WEST. I started to try to debug the createDateFromServerString() function, and it seems to me that it is not extracting properly the timezone offset from the server string, so I ask you if it is possible to instruct me how to get real server strings or if you could post here some few actual lines.

Actually I patched inelegantly in the same function:

date.setUTCHours(hour-3);

It works, but it sucks!

Thanks!

Now, since we're back in BST, I may take another swipe at it.

Did you ever get an answer from Apple about this? I would sure like to fix the problem.

Thanks!