Javascript engine should follow what OS can give…

so your DB really holding data with very old date?

anyway, in MySQL, Time object is not really a Time teller… should use timestamp or datetime object instead.

In Windows:
Java Apps returns +7:30GMT on 1970-Jan-1st
Javascript (Firefox & IE) returns +8:00GMT on 1970-Jan-1st

In Linux:
Java Apps returns +7:30GMT on 1970-Jan-1st
Javascript (Firefox & epiphany) returns +7:30GMT on 1970-Jan-1st

i believe the javascript engine will just make use of the local machine timezone data… i’m not too sure how Linux Javascript engine can be different between OS since it should be tied up with browser. any readings which you found out the javascript engine between Linux FF and Windows FF are different?

I don’t need to have the timezone object. What I need is only the time, but java bundle it with timezone.

Timezone offset for Asia/Kuala_Lumpur is +8:00GMT since 1981 (Dec 31 23:30:00 to be exact). Before that, it was +7:30GMT, +7:00GMT, etc. See http://en.wikipedia.org/wiki/Malaysian_Standard_Time for a complete list of timezone history for Malaysia.

Before writing this blog post, I’ve also tested a simple Java program that return the timezone offset for Asia/Kuala_Lumpur on the date 1970-Jan-1st on both Linux and Windows. Both return me the same result: +7:30GMT. I believe the tzdata on both OSes are the same or have the same timezone history for Asia/Kuala_Lumpur.

The problem I encountered was mainly cause by the Javascript Engine and the design of java.sql.Time class. Let me explain it in more detail:

Javascript engine in Linux understand that, the timezone offset for Asia/Kuala_Lumpur on 1970-Jan-1st is +7:30GMT but in Windows, +8:00GMT is used. Why and what exactly is causing the difference? I do not know.

java.sql.Time is a class to represent a database type called time. It basically means, HH:MM:SS without any date info. Meaning just a time, that’s all. Instead of creating a new class just for that purpose, Java decide to inherit from java.util.Date. The javadoc for java.sql.Time says clearly that, the date portion of the class should be set to 1970-Jan-1st and should not be accessed.

Thus the following:

Database value is 00:00:00

java.sql.Time value is date=1970-Jan-1st, timezone=Asia/Kuala_Lumpur, millisec from epoch=-7.5*60*60*1000 (see bottom on how to calculate this value)

Linux javascript engine translate the value to “-7.5*60*60*1000″ + “+7:30GMT” = 00:00:00 (correct)

Windows javascript engine translate the value to “-7.5*60*60*1000″ + “+8:00GMT” = 00:30:00 (wrong)

Calculation of milisec from Epoch:
In the example above, the java.sql.Time has the value of 1970-Jan-1st, Asia/Kuala_Lumpur, 00:00:00 local time. Millisec from Epoch means the time on the same day but with the timzone of Greenwich. Thus, the above local date time will be translated to

1969-Dec-31st, Greenwich, 16:30:00 (human term)

1970-Jan-1st, Greenwich, -07:30:00 (computer term)

-7.5*60*60*1000=-27000000 milisec from Epoch (take note of the minus sign)

I cannot decide who is at fault here: The design of the java.sql.Time? or the Javascript engine?

the best way for me is to define a custom timezone object, so you may ensure the date is always consistent.

maybe you can try this in Java instead:

Timezone tz = Timezone.getDefault(); // local machine default timezone data
String[] tzs = TimeZone.getAvailableIDs(); // local machine available timezone ids
Timezone tzKL = TimeZone.getTimeZone(“Asia/Kuala_Lumpur”); // local machine timezone data for KL

i guess even for same timezone, Java will give you different answer for different OS.

Thanks, Dave