Converting unix timestamp to date after Daylight Saving Time change

Hello,
in one of the products we use the internal scheduler stores dates (and times) in an Unix-like format, that is seconds since 1st of January 1970. We have used this SQL to extract the actual date:
TO_CHAR(t.next_fire_time/(24*60*60*1000) +to_date('19700101020000','yyyymmddhh24miss'),'yyyymmddhh24miss')
Everything worked fine until the time has changed this weekend from UTC+2 to UTC+1 (we are located in Eastern Europe). Since then the query above returns one hour later than it should.
I.e. timestamp *1320067800000* is returned as *20111031153000* even thought correct is (and the actual time the event was scheduled) *31-OCT-11 02.30.16.000000 PM*
I found queries like this on different forums and no one seems to worry much about the daylight savings. Is this a configuration issue in the DB or is it a bug in our code?
I tried selecting the SESSIONTIMEZONE and DBTIMEZONE and both were +1.
Any help appreciated.

Your problem is hard-coded 2hour offset:
to_date('19700101<font size=5 color=red>02</font>0000','yyyymmddhh24miss')You need to calculate current offset to adjust it to current DST situation:
with sample_table as (
                      select date '1970-01-01' + 1320067800000 / 1000 / 3600 / 24 dt_utc from dual
select  dt_utc,
        dt_utc +
        extract(
                     timezone_hour
                from
                     from_tz(cast(dt_utc as timestamp),'utc') at time zone 'Europe/Prague'
               ) / 24 dt_prague,
        extract(
                     timezone_hour
                from
                     from_tz(cast(dt_utc as timestamp),'utc') at time zone 'Europe/Prague'
               ) tz_offset
  from  sample_table
DT_UTC              DT_PRAGUE            TZ_OFFSET
2011-10-31 13:30:00 2011-10-31 14:30:00          1
SQL> SY.

Similar Messages

  • Daylight Saving Time Changes in 2007 for USA

    Can anyone give me solution how to handle Daylight saving Time changes in 2007 in USA for JDK 1.3.x releases? We are using this due to some vendor dependency. We can�t upgrade to higher versions up to middle of the 2007. I would be thankful if somebody gets back to me.

    I have a similar issue where we cannot upgrade the jdk 1.1 without involving a lot of effort. If we keep the same old jdk, can someone tell me if use of Date and Calendar api will be impacted by the Daylight saving change.....provided the timezone is default and not explicitly set to EST. Also there isnt any timezone related buss logic.

  • Support for US Daylight Saving Time changes in 2007

    The Start and Stop dates for Daylight Savings Time in US will change from 2007.
    From Sun's bug database, it looks like Sun has handled this Daylight Saving Time changes in JDK 1.5.0_06.
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317178
    Does anyone know if they have handled this in earlier JDK releases (1.3.x, 1.4.x)? If not, do they have any plan to handle these changes?

    1.3.1_18 had a timezone change.
    http://java.sun.com/j2se/1.3/ReleaseNotes.html
    1.4.2_11 had some timezone changes (but now there is a 1.4.2_12, so use that).
    http://java.sun.com/j2se/1.4.2/ReleaseNotes.html
    Not sure exactly what the timezone changes were, but check the release notes or give those JDKs a try.

  • USA Residents:  Early Daylight Saving Time *Changes*.

    Apparently, a few folks are unaware of the changes & patch because for various reasons they do not check and/or use their Software Update Control Panel.
    http://docs.info.apple.com/article.html?artnum=305056 About Daylight Saving Time changes in 2007

    I have a similar issue where we cannot upgrade the jdk 1.1 without involving a lot of effort. If we keep the same old jdk, can someone tell me if use of Date and Calendar api will be impacted by the Daylight saving change.....provided the timezone is default and not explicitly set to EST. Also there isnt any timezone related buss logic.

  • Multiple instances spawned after daylight savings time change

    This is a known issue and there is an SAP Knowledge Base Article created on this issue:
    1448881 - Multiple instances spawned after daylight savings time change
    Below is the information from the SAP Knowledge Base Article:
    Symptom
    Scheduled reports that are supposed to run once a day, run multiple times.
    Duplicate instances are being created.
    Environment
    BusinessObjects Enterprise XIR2 SP5
    BusinessObjects Enterprise XIR2 SP5 + FP5.x
    Reproducing the Issue
    A report is scheduled to be run on a daily basis - this is a Recurring schedule.
    Normally the report runs once a day, at a particular time.
    After Daylight Savings Time change, the report runs at the specified time, but immediately after the successful instance, another instance is spawned.
    Many more instances spawn after each instance completes.
    Cause
    This is a known issue: ADAPT01318487. This issue is because of DST and how our code handles this change.
    Resolution
    There is currently no known fix for this issue. There is however a script that can quickly resolve the problem.
    The issue it seems is related to Daily recurring schedules.
    What this script will do:
    it will run a query to display all your DAILY Recurring jobs
    you will have the option to choose your jobs and reschedule them by 1 hour
    you will then highlight the same job and change them back by 1 hour
    by modifying the schedule times, you are modifying the schedule itself and this will keep the issue of duplicate instances from occurring.
    Exact Steps to Complete:
    Stop the Job Servers.
    Double click on the .hta file.
    Change the System Name to that of your CMS name.
    Add the Administrator's password.
    Click Logon.
    Click List All Recurring Instances.
    Select All.
    Make note of what it says in: Schedule Selected Recurring Instances: Should be 1 hr earlier.
    Click Reschedule Selected Recurring Instances.
    Choose All instances again and change Schedule Selected Recurring Instances to 1 hour Later.
    Click Reschedule Selected Recurring Instances.
    Now start your Job Servers.
    The issue should not occur again.
    The Script is attached here, but please review the SAP Knowledge Base article 1448881 as well

    Hi Nicola,
    - The multiple spawned instances issue ONLY affects XI3 SP3+ only.  For XI3 SP1 and SP2 all Fix Pack levels this is not an issue as it was introduced as a problem in SP3.
    - 1568239 notes the Java version and can apply to all O/S environments and is updated to reflect that.
    If you are located in Europe you can also apply the patches in advance of the DST change to avoid the problem.  If you are in Americas at this point utilizing the clean up scripts for this year is the approach needed to clean up the spawned instances and reschedule the existing schedules.
    Thanks,
    Chris

  • Daylight Saving Time Changes for 2007

    Hello Friends
    Sun's J2SE 1.4.2_11 has taekn care of the new Daylight Saving Time changes in accordance with The Energy Policy Act of 2005. Does anyone know if bea has incorporated same changes to their Jrockit, if so then starting which version.
    http://java.sun.com/developer/technicalArticles/Intl/USDST/
    Thanks for the answers in advance.
    Regards
    Rajeev Bhogal

    Hello All
    We currently compile and run our application with Jrockit 1.4.2_04 (build 1.4.2_04-b05), if we change to minor version 11 for 1.4.2 should we recompile the application. I would think that DST related binaries would only be called at run time not compile time, however I am far from being a compiler expert. Can any learned friend shed some light.
    Henrik what do you think.
    Regards and Thanks
    Rajeev Bhogal

  • App. Servers Patches (Fix) for U.S. Daylight Saving Time Changes in 2007

    Hi --
    I am having an issue with Oracle 10g Application Server (9.2.0.4 and 10.1.2) and BEA Weblogic (8.1.4) upgrading their corresponding JDK's to resolve the Daylight Saving Time Changes. Right now these app servers are using SUN jdk version, whcih prone to the DST issue, less that JDK 1.4.2.11.
    The details about the DST can be found at this location:
    http://java.sun.com/developer/technicalArticles/Intl/USDST/
    Thanks

    Hi,
    Thanks for posting.
    Metalink Note:403311.1 for DST E-Business Suite (EBS))Patches.
    Regards,
    Phani.K

  • Conversion mapping is losing time zone data during daylight saving time

    We have a problem with conversion of Calendars to timestamp with timezone for the last hour of Daylight Saving Time (e.g. 01:00 EDT - 01:59 EDT) where it is being interpreted as Standard Time which is in reality 60 minutes later.
    We've written a JUnit test case that runs directly against TopLink to avoid any issues with WAS and its connection pooling.
    The Calendar theDateTime comes from an object called TimeEntry which is mapped to a TIMESTAMP WITH TIMEZONE field using conversion mapping with Data Type TIMESTAMPTZ (oracle.sql) and Attribute Type Calendar (java.util).
    We are using:
    Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build Patch for Bugs 5145690 and 5156075)
    Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
    Oracle JDBC driver Version: 10.2.0.1.0
    platform=>Oracle9Platform
    Execute this Java:
    SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy HH:mm z");
    TimeZone tzEasternRegion = TimeZone.getTimeZone("US/Eastern");
    Calendar theDateTime = Calendar.getInstance(tzEasternRegion);
    theDateTime.setTime(format.parse("10/29/2006 01:00 EDT"));
    Persist to the database and execute this SQL:
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides the following results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
    The wrong time zone is in the database. It should be EDT -4. Let's test the SQL that should be generated by TopLink. It should look like the following.
    Execute this SQL:
    UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 US/Eastern','mm/dd/yyyy HH24:MI TZR') WHERE (time_table_id=1)
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides the same results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
    Now, execute this SQL:
    UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 EDT US/Eastern','mm/dd/yyyy HH24:MI TZD TZR') WHERE (time_table_id=1)
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides better results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EDT -4
    The correct time zone is now in the database. Let's test reading this with the following Java:
    System.out.println("cal= " + theDateTime);
    System.out.println("date= " + theDateTime.getTime());
    System.out.println("millis= " + theDateTime.getTimeInMillis());
    System.out.println("zone= " + theDateTime.getTimeZone());
    This provides the following results:
    cal= java.util.GregorianCalendar[...]
    date= Sun Oct 29 01:00:00 EST 2006
    millis= 1162101600000
    zone= sun.util.calendar.ZoneInfo[id="US/Eastern",...]
    The TimeZone object is correct since we are using the US/Eastern regional time zone, but the millis are wrong which makes the time EST instead of EDT. The millis should be 1162098000000.
    The conversion from java.util.Calendar to TIMESTAMPTZ loses the actual offset when setting to a regional time zone. It can maintain this info by specifying it explicitly.
    The conversion from TIMSTAMPTZ to java.util.Calendar also loses the actual offset even if the correct offset is in the database.
    Has anyone else encountered this conversion problem? It appears to be a conversion problem in both directions. I know that the Calendar is lenient by default and will assume Standard Time if time is entered during the repeated 1 o'clock hour at the end of Daylight Saving Time, but the Calendars we are using are explicit in their time, so this would be classified as data corruption.
    Nik

    Opened an SR. Looks like there is a problem with conversion either in TopLink or in JDBC.

  • Recurring events off by 60 minutes after daylight saving time switch

    I searched but didn't find this exact issue anywhere. Following this past weekend's switch to Daylight Saving Time (DST), iCal recurring events have been shifted one hour later. It is a problem that I encountered with my own web calendaring application, wherein the offset between UTC and a given time zone changes with the coming and going of DST. I am curious why Apple has never instituted a fix for this, especially considering that the fix is so simple. All that must be done is detect whether the original datetime is in DST or not. If it is not, and the given recurrence is, then you must subtract 60 minutes from the recurrence's datetime. Similarly, if the originating datetime is in DST, and the given recurrence is not, then you must add 60 minutes to the recurrence's datetime.

    I have the same problem but much worse. Only 5 of my 18 recurring weekly events have shifted, so I didn't realize that anything was off until I missed one of my classes today. This seems weird....

  • Oracle Fix for U.S. Daylight Saving Time Changes in 2007

    Hi --
    Does any one know that if Oracle 10g Application Server (9.0.4) or Oracle 10g Application Server (10.1.2) as a fix for this issue.
    Summary of the Issue: Information about the impact of the US Energy Policy Act of 2005, which changes the effective dates of US Daylight Saving Time (DST) in 2007 for the US. The passage of the Energy Policy Act of 2005 alters the Daylight Saving Time (DST) start and stop dates by four weeks. Extended Daylight Saving Time will begin in March of 2007.
    The details for the issue can found at this location:
    http://java.sun.com/developer/technicalArticles/Intl/USDST/
    Thanks

    Hi,
    Thanks for posting.
    Metalink Note:403311.1 for DST E-Business Suite (EBS))Patches.
    Regards,
    Phani.K

  • Problem with SLQ Date and Daylight Saving Time

    Hi everybody!
    It seems, that when I have a date in the database, which falls on start of the daylight saving period, it is converted to the previous date.
    Example: '2001-10-13' will become '2001-10-12' after doing a date = rs.getDate() and then converting back using date.toString().
    This caused a lot of trouble because the date value is part of an unique key constraint!
    Currently I wrote a wrapper method, which obtains the date as string and converts this one into a date by setting the hours to 12:00.
    Does anybody know a straighter way to avoid the conversion?

    Because the default time zone is using day light saving time. To remove this feature, reset your default time zone at the very beginning of your program:
    TimeZone.setDefault( new SimpleTimeZone( TimeZone.getDefault().getRawOffset(), TimeZone.getDefault().getID() );

  • Daylight saving time changes - Netweaver Java

    Hi,
    For DST, we are planning to shutdown ABAP systems. What about JAVA systems, shall Hi,
    For DST , we are planning to shutdown ABAP systems. What about JAVA systems, shall we need to shutdown JAVA systems??
    It would be great, if any one can provide any document or OSS notes for JAVA systems.
    Thanks & Regards

    Hi Srinivas,
    Sorry that I don't know any Note covering all different platforms and releases...
    My experience is that for non-active Java engine on Windows, the Java engine would run fine without shutdown. For some platform(s), it is required to shutdown ABAP stack, so the Java engine will be down for ABAP+JAVA systems.
    If you give the release and the platform details, manby someone has the answer.
    Best regards,
    Victor

  • CreateODBCDateTime monkeys with Daylight Saving Time!!

    If one uses CreateODBCDateTime to convert a date into the
    proper format for storing in a SQL Server database, and one runs
    this operation on a date between 0200 and 0300 on the day that
    Daylight Saving Time changes, the function will change the time
    forward or backward one hour. IT WILL DO THIS EVEN IF THE DATE YOU
    ARE STORING IS UTC, thus rendering UTC times INVALID because they
    do not have DST. Why does this function monkey with DST at all?

    I have several international web sites on this server, one of
    which has over 100,000 users who have contributed over 70 million
    records, all with UTC timestamps. The problem occurs during the one
    hour period EVERY YEAR when daylight saving time is started. It
    does not do this in the fall when the time reverts. So, yes, the
    problem only occurs during 1 hour out of 8,760 hours, but when you
    start with 70 million records over 5 or 6 years...
    But the danger is for anybody who stores or manipulates a
    date/time OTHER THAN the date/time that is being used internally to
    the server. In other words, if your server is set to Central Time,
    and you have users in Hawaii or Arizona who need to store their own
    date/time, it is likely to apply Central Timezone RULES to that
    date/time, even if Hawaii and Arizona don't use DST.
    Let's say you're scheduling operating rooms in a hospital in
    Honolulu. All the CF routines are going to make sure to shift those
    times forward an hour without warning, have a nice day. In my case,
    it is happening with UTC, but it could be ANY time zone that has
    different rules than the ones on your server.
    Yes, I can probably figure out a different way to process
    times, but this is a massive system with thousands of different
    templates. In fact it affects several pretty massive software
    systems with millions of lines of code, so it's not as if I can
    just change a few SQL queries and be done with it.
    It probably should be a rule for anybody operating a
    ColdFusion server in an international setting, where dates and
    times from different regions might need to be stored in a database,
    to set up the server on UTC time just to avoid this problem.
    Me, I have to
    a. find all the places this will affect in thousands of lines
    of code,
    b. try to decide what impact going to UTC on the server will
    have on things like scheduled tasks, email servers, etc,
    c. then figure out whether there is any way to repair tens of
    thousands of corrupted records

  • Exchange Active Sync UTC Daylight Saving Time

    Color me a bit confused. I am attempting to write an IOS client application to communicate with Exchange ActiveSync and display calendar information. But I am seeing some conflicting information in the protocol docs when compared to what I am getting from
    Exchange. Either that or I am somehow misinterpreting one or the other.
    My intent is to save an appointment in my local database in Coordinated Universal Time and then have the UI read in the information and display it as appropriate to the local timezone. In this way an recurring appointment created before daylight saving time
    for Noon will still be at the same time of day in local time as an appointment created during daylight saving time for noon. But they are not.
    My understanding of the documentation is as such:
    In MS-ASCAL pdf section 2.2.2.40 (roughly page 34) it says for Start Time that : ...the value of this element is a dateTime data type as specified in MS-ASDTYPE section 2.3.
    Moving to MS-ASDTYPE section 2.3 (roughly page 7) the dateTime value is specified in the format of ISO-8601 and all dates are given in Coordinated Universal Time (UTC)
    Looking up coordinated universal time I see that UTC does not changed with the seasons as local or civil time does and therefore DOES NOT support daylight saving time. This makes sense, as DST is decidedly local and is ignored by many areas. You cannot know
    from the perspective of UTC whether or not to apply a DST offset without knowing what timezone and area the time represents, therefore no daylight saving time can be supported. Based on this information I should be able to just slap the dates into my database
    as they are and merely have the UI adjust itself to display them properly.
    However, as a tested I began seeing a divergence of an hour between the two appointments in the database before the UI has even read them. To confirm this I created two recurring appointments representing Lunch at 12 noon local time. One that starts on March
    1st 2014 (Standard Time) and one that starts on March 10th 2014 (daylight saving time) in the eastern timezone. This should be March X 2014 at 1700 hours in both cases should it not?
    In the WBXML/XML that I am receiving I am getting two different times. The appointment that starts during standard time gives me a start time of 20140301T170000Z. The appointment that starts after daylight saving time is in effect locally gives me 20140301T160000Z.
    The difference between the two times is 1 hour, which is the daylight saving time offset. It is my perception based on everything that I have read both in the microsoft protocol documentation and outside it that these two times should be the same and that whatever
    client that gets to display them should be the one putting the offset in place as needed. Noon local time is noon local time but local time is the province of the local municipality/timezone, not that of UTC.
    So my question is what exactly is going on here? Are the start/stop/date stamp date times in UTC or not. If they are in UTC, then why are they offset by an hour instead of being at the same time? Obviously outlook displays these correctly for local time,
    because both appear at noon. But in my case my database contains locally adjusted times instead of the UTC times I thought I was getting which is throwing off when those appointments appear in the UI.
    Can someone please clarify what's going on here and what I should be seeing?
    Thanks.
    E

    Thanks for the reply, however after doing what is said the problem still remains. I did not try the manual approach, because of the time that would take with calendars that change at least daily.
    I am running the latest update of ICal and IPod, you would think this would have been addressed with one of the updates to allow the sync to work correctly with 5th generation IPods.
    I am going to try and turn off day light savings time set the clock to a Central Time zone and see if that works, I do not cross time zones much, anymore.
    MacBook   Mac OS X (10.4.9)  

  • BO-XI R2 daylight saving time

    The time in infoview has not changed to accommodate the daylight saving time change.
    Version:  11.5.8.8265
    Tried to install xir2 edst patch (CHF15_DST), when doing so I get a message stating "MHF1 is needed as prerequisite"...when I try to install MHF1, receive message "No supported XIR2 products detected"
    Please advice, thank you.

    Symptom
    The Integration Kit for Baan driver displays incorrect time data in reports. The time is off by an hour between the dates marking the old Daylight Saving Time (DST) and the new DST change.
    Cause
    DST has been changed to occur earlier in the year. The Integration Kit for Baan does not pick the new settings up.
    Resolution
    There are files called ZONEFILES on the BAAN Server. These files must be already updated on the Baan server side.
    The Integration Kit for Baan installs our own version of these files in the following folder:
    \Baan\Native\lib\ZONEINFO
    on the hard drive where the Integration Kit is installed.
    Back up these files on the Crystal Reports/Business Objects XI computer, then put a copy of the ZONEFILES from the Baan Server to the computer where the Integration Kit for Baan is installed.

Maybe you are looking for

  • How can I get an RTF file to open properly in MS Word?

    I'm using Coldfusion 8 and trying get it to export to Microsoft Word an RTF file  that was also created in Word, and is stored on the server. The problem is that when Word opens from the browser, it displays the RTF code for the document as if I'd op

  • Can't access iTunes store on new Macbook air

    Hi - I just bought a Macbook air and I've synced my phone to it, but when I try to open the iTunes store, all I get is a blank screen.  What do I need to do? Thanks!

  • Exception handling in App. package PeopleCode

    Hi, I am accessing a table that is on remote database using DBLink for an update/insert operation using SQLExec. I am trying to implement exception handling to account for the scenario where the remote database is offline so that transaction can cont

  • I am having using my mail accounts on multiple computers

    I have all of my email accounts (mostly gmail) setup on my Mail application on my iMac, Macbook, and iPod touch. I am having trouble with receiving all my mail. Some emails show on one computer and never show up anywhere else. Does anyone know if the

  • Depreciation of the Previous Fiscal Year want to post in Current FiscalYear

    I have already posted Depreciation for the year 2008 by using Planned Posting Run (T.code:AFAB) After that I have created one Asset Master (T.code: AS01) In AS01, Depreciation tab , I have set Depreciation starts from 19.09.2007, i.e. Fiscal year: 20