New error in tomcat5 and java7 U21

Question

I've got a system develop in Java + MySql + Tomcat5. I used to work with Java6, but I updated my machine to win8 with java7 and when I run my servlet I got this error from Tomcat. Does anybody know why it's happening this or how to fix it.

javax.servlet.ServletException: java.lang.IllegalArgumentException: HOUR_OF_DAY: 0 -> 1
    at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2764)
    at java.util.Calendar.updateTime(Calendar.java:2606)
    at java.util.Calendar.getTimeInMillis(Calendar.java:1118)
    at java.util.Calendar.getTime(Calendar.java:1091)
    at com.genexus.GXutil.resetTime(Unknown Source)
    at com.genexus.db.driver.GXConnection.isNullDate(Unknown Source)
    at com.genexus.db.driver.GXResultSet.getGXDate(Unknown Source)
    at paddmwl__default.getResults(paddmwl.java:911)
    at com.genexus.db.DataStoreProvider.readNext(Unknown Source)
    at com.genexus.db.DataStoreProvider.execute(Unknown Source)
    at paddmwl.execute_int(paddmwl.java:44)
    at paddmwl.execute(paddmwl.java:30)
    at hconsola_impl.e202U2(hconsola_impl.java:3490)
    at hconsola_impl.evt2U2(hconsola_impl.java:478)
    at hconsola_impl.dispatchEvents(hconsola_impl.java:180)
    at hmasterpageww_impl.evtCH2(hmasterpageww_impl.java:215)
    at hmasterpageww_impl.wsCH2(hmasterpageww_impl.java:146)
    at hmasterpageww_impl.webExecute(hmasterpageww_impl.java:53)
    at hconsola_impl.webExecute(hconsola_impl.java:62)
    at com.genexus.webpanels.GXWebObjectBase.doExecute(Unknown Source)
    at hconsola.doExecute(hconsola.java:19)
    at com.genexus.webpanels.GXWebObjectStub.callExecute(Unknown Source)
    at com.genexus.webpanels.GXWebObjectStub.doPost(Unknown Source)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419)
    at org.apache.catalina.servlets.InvokerServlet.doPost(InvokerServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
    at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
    at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
    at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
    at java.lang.Thread.run(Thread.java:722)

    com.genexus.webpanels.GXWebObjectStub.callExecute(Unknown Source)
    com.genexus.webpanels.GXWebObjectStub.doPost(Unknown Source)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419)
    org.apache.catalina.servlets.InvokerServlet.doPost(InvokerServlet.java:169)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

I have now idea why this is happening and I don't get any information from google. Thanks for your help. Have a good day!! :)

Answer 1

I have seen this exception thrown due to DST (daylight savings time) constraints when parsing dates in Brazil.

It seems in the case at hand GregorianCalendar is throwing an IllegalArgumentException due to DST constraints. When the DB driver tries to read a date field, the stored date is not a valid date, according to GregorianCalendar, because the time portion is zero (midnight) and there is no midnight for that specific day.

I know it sounds strange, but the problem is the way DST is defined (at least thats the case in Brasil, I dont know about other countries), where we have the clock change from midnight to 1am when we enter DST. This causes the phenomenom of not having midnight, since it is replaced by 1am instead, and this causes the problem we see here. In the US we dont have this problem because DST changes at 3am, so midnight is always there where it should be. I wonder how the 3am - 4am times are handled to avoid this kind of quirk.

The only way I know of dealing with this issue is to never store dates with zeroed time portions.