US2007DST and Firewall Analyzer

JAVA TimeZone Handling:

Java gives the number of milliseconds since 197O Jan 1 UTC to the current UTC as a result of System.currentTimeMillis(). When you ask current time from an IST machine (meaning a machine with Timezone set to IST), it adds + 5 Hours 30 mins to the current UTC seconds and gives us the time.

So I believe always java gets the UTC milliseconds from the OS while loading jre. It is NOT getting the timezone deviations (IST = UTC + 5:30) with respect to UTC from the OS. It is just getting the timezone value (Asia/Calcutta) and absolute UTC millisecons from the OS.

Also it maintains a separate database of files that store timezone deviation values and daylight saving values. In that database, DST values are hardcoded. For example US/Pacific timezone has daylight savings starting from first sunday of April. i.e on that day when their clock reaches 10 AM, they will turn their click to 9 AM, thus they are saving 1 hour energy. So existing java database has hardcoded DST value starting from first sunday of April. Now in 2007, they announced that DST will commence at Second sunday of March.

Mysql TimeZone handling:

On the contrary Mysql gets the timezone as well as timezone deviations from the OS itself (at least in our products). It also gets UTC milliseconds from the OS. When you say unix_timestamp(now()) it gives the difference in seconds between 1970 Jan 1 UTC to current UTC time.

Also when you do from_unixtime(seconds), it gets the UTC time by adding the given seconds to 1970 Jan 1, then it calculates the current time by manipulating with the local timezone deviation with the UTC. For example after getting UTC time, it adds + 5 Hours 30 Minutes to get IST time.

Daylight Saving Time considerations for Log Analyzers.

I considered the following use cases that are dealing with time.

* Storing System.currentTimeMillis() in mysql tables.

* Storing YYYY:MM:SS HH:mm:SS format in mysql tables.

* Storing System.currentTimeMillis() in the java memory.

* Date Manipulation in Various formats like YYYY:MM:SS HH:mm:SS etc.

* Executing time related functions in Mysql (from_unixtime(), unix_timestamp()).

Assume DST starts at 11 th March 2006 at 2 AM. i.e when the clock reaches 2 AM, they will shift the clock to 3 AM. So assuming device time is also changed with respect to DST, our graphs will not show any data between 2 AM to 3 AM since your device will not send data at the time. Schedulers will continue to work (hoping that all schedulers are doing nextSchedulingTime <= currentTime) with no loss of data.

Assume DST ends at 7 th November 2 AM. They will shift the clock from 2 AM to 1 AM. So assuming device time is also changed with respect to DST, we will get double the data in our graphs especially from 1 AM to 2 AM. As for the scheduling is concerned we will loose 1 hour polling data. For example as per (UTC – 4), we would have scheduled a polling at 1:05 AM, but it would be delayed by an hour as the system follows (UTC – 5) in daylight savings mode. So scheduler will RUN with out any problem. But there will be a data loss in the transition period if you store next scheduling time as string i.e YYYY-MM-DD HH:mm:SS. There will not be any data loss if you store System.currentTimeMillis() as next scheduling time. Most of the cases we follow System.currentTimeMillis().

Effect of current Day light Saving time changes in 2007:

Till last year 2006, daylight-saving time has begun on the first Sunday of April and reverted to standard time on the last Sunday in October. But beginning this year the daylight-saving schedule will be extended by a month, with the period beginning on the second Sunday in March and ending on the first Sunday in November.

As told earlier, java maintains its own database and even after applying OS patch for the above change our products will not obey OS patch. So java has to be updated to solve this issue. As our mysql uses OS timezone deviations, there is NO NEED to patch mysql.

Java Patch:

http://java.sun.com/developer/technicalArticles/Intl/tzupdatertool.html

http://java.sun.com/javase/downloads/index.jsp (you need to register to get this jar)

Mysql Patch:

http://dev.mysql.com/downloads/timezones.html

I presume for all cherry products, this latest DST change will affect ONLY the client where we show FROM and TO,Last Hour, Last Day data etc. Other than that we will not have any issues when compared to last year. If you want to fix this locally kindly follow the below procedure.

Local Test Up:

1. Execute the following java code

It will print timezone start and end dates make a note of it. It would give DST starts at Ist week of April.

2. Execute the following. You can get the tzupdater.jar from SUN as given in the above link

Make sure you do not get any errors.

3. Now execute the same command given in the first step It should give DST starts at 2 week of March.