Fall Daylight time change & 9i

I am a Unix system administrator and not DBA.
We have a mission critical DB application running on HP-UX 11.23 Itanium.
With forthcoming Fall daylight change the time would bounce back from 2AM to 1AM. DBAs are saying the change would create a mess with the application. I am not sure how much the actual application or jobs are dependent on time and how this affect to oracle itself. DBAs are asking a way to slow down the system clock so that downtime could be avoided.
I want to know how it is being taken care at other places
Is it possible to have smooth transition of time without affecting the application operation?
I read there are daylight datatypes in 9i, but I am not sure if they can take care of this change and oracle level ( recovery etc.. ) and application DB transaction level?
Will they help to have zero downtime?
I would appreciate your feedback or experience suggestions.
Thanks in advance

Thanks Pierre for quick reply.
I referred those documents and as you said things are dependant on SYSDATE function would be affected. This function could be used in many PL/SQL codes/jobs of the application and would certainly affected by change in system clock.
Referring the doc 149120.1 , I guess the Timezone/daylight support is added in the oracle 9i so one can use those datatypes within database (part of globalisation of DB). This is nothing to do with SYSDATE or support ability of oracle to take care of PL/SQL application code/job to run without problem in case system clock changes. Am I right?
The application is running 24x7. Are you aware of any work around in such situation to have smooth operation ( business continuance) ?
I think this situation might be there with most of the businesses, how they do tackle thie time change?
Any guidance would be appraciated.

Similar Messages

File modification times affected by Daylight saving changes?

After daylight time changes Dreamweaver warns me about files on the server modified since I put them last time.
So what is stored in my local computer and the server date's are off by one hour.
At first I thought some hacker modified the files exactly one hour after I did to make less obvious the modification time, but that's not the case.
It doesn't happen one hour after, nor a whole month. It always happened with old files, and now it makes sense it only happens after a daylight saving shift.
Is there any way to fix it?
Is there any time zone or similar setup I need to make?
My computer always has the correct time.
I already spoke with the host and they don't find any issue nor malicious code modifying the files. Only my IP has modified files.
Thanks.

Do you only work from one system?
I have at least three that I do edits and uploads from, and I see this all the time when I'm not on the machine I last uploaded from.

CF MX and Daylight Savings Time Change

Next year 2007, the Daylight Saving day (chaning the clocks
for spring and fall) will be changing. The Spring date will be a
month earlier and the fall date a month later then it has been for
years.
How will the Cold Fusion Server for MX 7+ handle this? Will
it use the server time or use the internal CF Server clock?
Thanks.

My problem is that now CFMX 6.1 thinks that it is 8 hours
later in the day
than it really is (it is stuck on GMT now) and I am unable to
get CFMX to
acknowledge the operating systems clock. :-(
"GregK" <[email protected]> wrote in message
news:eord35$5mq$[email protected]..
The technote for this issue:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470
has
another
link to a technote which addresses null pointer exceptions
after upgrading
the
JVM on CFMX 6.1 systems:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400232
The hotfix
described in that technote gives a fix for CFLDAP and
CFSERVLET tags after
the
new JVM is installed.
The important thing to note is that Adobe feels that
daylight savings time
will indeed present a problem for ColdFusion applications.
Unfortunately,
the
problems are not explained in any detail. I can guess that
functions like
DateDiff( ) may calculate incorrect values when spanning the
changed weeks
of
daylight savings time. As others have suggested; however,
simply retrieving
the system time, i.e. Now( ) function may not be affected as
long as the
operating system clock is set correctly.
Hope that helps.

All Event times change with Daylight Savings time

With the time change associated with daylight savings time (March 8 2008) all my event times were changed by one hour. EG: events that were 8:45 am are now 7:45 am. I have tried using Time machine to restore to pre March 8 status,but an adjustment takes place and the events remain 1 hour ahead. I have looked through the discussions pages and don't even see the issue identified. I have looked through the menu and preference items and find nothing to help.
I am surprised not to find this a front page topic today, March 9 2008.
Can anyone offer some help ?
Bill Mullen

Michael,
I never have changed time zones. Are you suggesting I should have time zone support enabled ?
I just tried turning on Time Zone Support, then restoring my calendar using Time machine. No change here.
As I mentioned earlier, this same problem occurred in the fall (although I don't remember which way the event times moved), this time they moved forward. At the Fall change I was using a Mac G4, which I used as a target to build this machine. The only thing I can think of that makes me unique (although I'm not in that small of a group) is that I have altered one of the files in iSync to allow iSync to sync calendar events with iCal. The syncing has always worked OK.
Right now I'm leary of attempting to do anything with iSync. I'm also finding it difficult to believe I'm not one of 10,000 people experiencing the same problem, but I don't see any other posts.
I found a time zone in south america which returns my times to the correct figure, with time zone support enabled, but that looks like a deeper hole to dig out of.
Still stuck,
Bill

IdM Scheduler and Time Change to Daylight Savings Time GMT to BST

This isn't really a 'question' , but just a topic for discussion.
We're not live yet, but will be by the time the clocks go back. So I'm just interest to hear everyone's experiences and any issues with regards to the switching to / from DST
I did some "interesting" (or not) tests last night to see what happens with Pending Values which are due to take effect at the time change threshold of 01:00 GMT when switching to Daylight Savings Time (BST) GMT +0100.
It seems as if the IdM scheduler keeps going according to UTC or GMT. However any values provisioned to target systems or to local tables using the ddm.datetime8601 system variable are in local time according to the runtime server or SQL server's locale settings.
I set up a task to output from a javascript the current system date
using the following in the functions.
currentTime = new Date();
return currentTime.toString(); // returns Locale Time String
currentTime = new Date();
return currentTime.toUTCString(); // returns UTC Time String
in the same pass I also output the ddm.datetime8601 system parameter and the ddm.time24 system parameter.
This task was to update a comment on an entry and Scheduled to run at 00:00:00 and was executed at 00:00:06 GMT all times were still in GMT as expected.
Local Time: Sun Mar 27 00:00:06 GMT-0000 (GMT) 2011, UTC Time: Sun, 27 Mar 2011 00:00:06 GMT, ddm.datetime8601: 2011-03-27T00:00:06, ddm.time24: 00:00:06
This task was scheduled at 01:00:00 in IdM and was exectued at 01:00:08 GMT by the runtime, and you can see the local time is being correctly reported as 02:00:08 BST. Note also the ddmdatetime8061 is also 02:00:08 i.e. BST.
Local Time: Sun Mar 27 02:00:08 GMT+0100 (BST) 2011, UTC Time: Sun, 27 Mar 2011 01:00:08 GMT, ddm.datetime8601: 2011-03-27T02:00:08, ddm.time24: 02:00:08
In the database the entry values MXI_VALUES ModifyTime field has the GMT / UTC timestamp.
I also set up some pending value objects to be applied at 00:59:59 and 01:30:00 to see if the 01:30:00 would be 'skipped' as the locl clock change would've gone from 00:59:59 to 02:00:00. Well the pending values were correctly applied and expired and no 'lost' transactions happened as a result of the change.
So essentially it seems to me that the IdM runtime and scheduler times are all based on UTC / GMT.
I guess it's only an issue twice a year if you're expecting something to happen at a specific local time 01:00:00 or if you've got a global user base and their account expiry should be in each user's own country's local time. In these cases, it would seem that you'd need to convert the schedule times and pending value times to UTC first before setting them in the database.
Has anyone else had any issues, thoughts, questions or suggestioins on scheduling tasks which span the DST time change when switching to and from Daylight Savings Time.
Edited by: Paul Abrahamson on Mar 27, 2011 10:51 AM

Read here:
http://www.appleinsider.com/articles/10/10/11/applesays_ios_software_update_to_fix_pesky_alarm_clockbug.html

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

Time change for daylight savings and Alarms not working correctly

we have 3 iPhones in our house. 2 were set to auto time change for daylight saving and one wasn't. 1 did the auto time change with out an issue and all alarms worked ok. The other 2 have had issues with not been able to set the alarms ie set alarm for 0630 and it goes off at 0530 even though the time is set correctly. The 1 that was set to autotime worked fine until I switch auto time off, now the alarms on this one wont work either. well they work but just at the wrong time. The 3rd phone will allow alarms to be set, but the alarm will go off an hour earlier and this phone will not allow the alarm to be set for 0630 at all.
Has anyone had this issue and resolved it. It makes getting up for shift work a right pain..

Read here:
http://www.appleinsider.com/articles/10/10/11/applesays_ios_software_update_to_fix_pesky_alarm_clockbug.html

2007 US Daylight Savings change time zone support in JDK 1.3

Sun has supported the 2007 US Daylight Savings change in recent versions of its JDKs 1.4 and 1.5. It has made partial Daylight Savings changes to JDK 1.3, but it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone.
Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3.
If any Sun Java staff can explain the reasons for being unable to implement the change in 1.3 (or at least some kind of workaround that an individual JVM user could enable), please fill me in. Any pointers on cleanly setting up a custom workaround would be valuable too.
If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround?
More details....
What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application.
JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates.
JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly.
If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds:
1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible.
2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones.
Prior related Java Forum topics:
* http://forum.java.sun.com/thread.jspa?forumID=31&threadID=645874 (Java Essentials - Java Programming) winds up referencing the JDK 1.4 patch as a solution, and there is some discussion about how future/historic dates affect applications
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=735038 (Deploying - Java Upgrade) just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=717268 (Deploying - Java Upgrade) also just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=37&threadID=703214 (Specifications - Java Virtual Machine (JVM)) also just talks about 1.4 and 1.5
Related Sun Java Bug Database bugs:
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates.
Other articles:
* Sun Java article http://java.sun.com/developer/technicalArticles/Intl/USDST/ refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5
* Server Side article http://www.theserverside.com/news/thread.tss?thread_id=42212 refers to fixes in 1.4 and 1.5 for the DST issue, and the discussion about 1.3 doesn't lead anywhere
Thanks for any info or advice available,
Jim

Hi KBarney
I think u have the correct data file. to make sure see the "zi" dir is backed up in ur java lib folder or not.
if u have suspicion than run the tzupdater tool again.
this tool must be run for each jre/java version on your machine separately.
I tried this on 1.4.2.13 and not on 1.5.0.10. here is the result:
C:\Program Files\Java\j2re1.4.2_13\bin>java -jar c:\tzupdater\tzupdater2006p\tzu
pdater.jar -t -v
java.home: C:\Program Files\Java\j2re1.4.2_13
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_13
JRE time zone data version: tzdata2006p
Embedded time zone data version: tzdata2006p
Validating the time zone data
Validation complete
C:\tzupdater\tzupdater2006p>java -jar tzupdater.jar test verbose
java.home: C:\Program Files\Java\jre1.5.0_10
java.vendor: Sun Microsystems Inc.
java.version: 1.5.0_10
JRE time zone data version: tzdata2006k
Embedded time zone data version: tzdata2006p
Validating the time zone data
/data/tzdata2006p.test:990: test failed: America/Managua
/data/tzdata2006p.test:1465: test failed: America/Havana
/data/tzdata2006p.test:1466: test failed: America/Havana
/data/tzdata2006p.test:1847: test failed: Cuba
/data/tzdata2006p.test:1848: test failed: Cuba
/data/tzdata2006p.test:2024: test failed: America/Campo_Grande
/data/tzdata2006p.test:2026: test failed: America/Campo_Grande
/data/tzdata2006p.test:2028: test failed: America/Campo_Grande
/data/tzdata2006p.test:2030: test failed: America/Campo_Grande
/data/tzdata2006p.test:2032: test failed: America/Campo_Grande
/data/tzdata2006p.test:2034: test failed: America/Campo_Grande
/data/tzdata2006p.test:2036: test failed: America/Campo_Grande
/data/tzdata2006p.test:2038: test failed: America/Campo_Grande
/data/tzdata2006p.test:2040: test failed: America/Campo_Grande
/data/tzdata2006p.test:2046: test failed: America/Cuiaba
/data/tzdata2006p.test:2048: test failed: America/Cuiaba
/data/tzdata2006p.test:2050: test failed: America/Cuiaba
/data/tzdata2006p.test:2052: test failed: America/Cuiaba
/data/tzdata2006p.test:2054: test failed: America/Cuiaba
/data/tzdata2006p.test:2056: test failed: America/Cuiaba
/data/tzdata2006p.test:2058: test failed: America/Cuiaba
/data/tzdata2006p.test:2060: test failed: America/Cuiaba
/data/tzdata2006p.test:2062: test failed: America/Cuiaba
/data/tzdata2006p.test:2471: test failed: America/Montevideo
/data/tzdata2006p.test:2472: test failed: America/Montevideo
/data/tzdata2006p.test:2475: test failed: America/Montevideo
/data/tzdata2006p.test:2476: test failed: America/Montevideo
/data/tzdata2006p.test:2479: test failed: America/Montevideo
/data/tzdata2006p.test:2480: test failed: America/Montevideo
/data/tzdata2006p.test:2483: test failed: America/Montevideo
/data/tzdata2006p.test:2484: test failed: America/Montevideo
/data/tzdata2006p.test:2487: test failed: America/Montevideo
/data/tzdata2006p.test:2494: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2496: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2498: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2500: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2502: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2504: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2506: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2508: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2510: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2516: test failed: BET
/data/tzdata2006p.test:2518: test failed: BET
/data/tzdata2006p.test:2520: test failed: BET
/data/tzdata2006p.test:2522: test failed: BET
/data/tzdata2006p.test:2524: test failed: BET
/data/tzdata2006p.test:2526: test failed: BET
/data/tzdata2006p.test:2528: test failed: BET
/data/tzdata2006p.test:2530: test failed: BET
/data/tzdata2006p.test:2532: test failed: BET
/data/tzdata2006p.test:2537: test failed: Brazil/East
/data/tzdata2006p.test:2539: test failed: Brazil/East
/data/tzdata2006p.test:2541: test failed: Brazil/East
/data/tzdata2006p.test:2543: test failed: Brazil/East
/data/tzdata2006p.test:2545: test failed: Brazil/East
/data/tzdata2006p.test:2547: test failed: Brazil/East
/data/tzdata2006p.test:2549: test failed: Brazil/East
/data/tzdata2006p.test:2551: test failed: Brazil/East
/data/tzdata2006p.test:2553: test failed: Brazil/East
/data/tzdata2006p.test:3451: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3452: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3453: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3454: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3455: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3456: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3457: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3458: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3459: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3460: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3461: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3462: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3463: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3464: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3465: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3466: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3467: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3468: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3469: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3470: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3471: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3791: test failed: ART
/data/tzdata2006p.test:3814: test failed: Africa/Cairo
/data/tzdata2006p.test:3844: test failed: Asia/Amman
/data/tzdata2006p.test:3848: test failed: Asia/Amman
/data/tzdata2006p.test:3852: test failed: Asia/Amman
/data/tzdata2006p.test:3856: test failed: Asia/Amman
/data/tzdata2006p.test:3860: test failed: Asia/Amman
/data/tzdata2006p.test:3887: test failed: Asia/Damascus
/data/tzdata2006p.test:3908: test failed: Asia/Gaza
/data/tzdata2006p.test:3911: test failed: Asia/Gaza
/data/tzdata2006p.test:3915: test failed: Asia/Gaza
/data/tzdata2006p.test:3919: test failed: Asia/Gaza
/data/tzdata2006p.test:3923: test failed: Asia/Gaza
/data/tzdata2006p.test:4035: test failed: Egypt
/data/tzdata2006p.test:4901: test failed: Australia/Perth
/data/tzdata2006p.test:4902: test failed: Australia/Perth
/data/tzdata2006p.test:4905: test failed: Australia/Perth
/data/tzdata2006p.test:4906: test failed: Australia/Perth
/data/tzdata2006p.test:4909: test failed: Australia/Perth
/data/tzdata2006p.test:4910: test failed: Australia/Perth
/data/tzdata2006p.test:4914: test failed: Australia/West
/data/tzdata2006p.test:4915: test failed: Australia/West
/data/tzdata2006p.test:4918: test failed: Australia/West
/data/tzdata2006p.test:4919: test failed: Australia/West
/data/tzdata2006p.test:4922: test failed: Australia/West
/data/tzdata2006p.test:4923: test failed: Australia/West
Validation tests failed.
-Ranjan

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.

Citadel time wrong after daylight savings change

I have just noticed that all of my previous alarms in Citadel are now
off by 1 hour after the fall time change. For example, an alarm that
occured at 4:00 am yesterday (and was in the Citadel database as 4:00
am yesterday), is now shown as 3:00 am after the time change.
Any work arond for this? I am running lookout 6.0
Also, is there a way to change the order of the date field in Citadel?
It displays as month first in the date colum. I would like YYYYMMDD
HHMMSS so when I export to Excel it will sort corectly.
Thanks in advance.

alan,
What Bob said is correct. You can change the way Excel formats
the date to however you want by right-clicking on the cells and
selecting Format Cells..., then clicking on either Date, Time,
or Custom, and changing the format that way, however this will have no
bearing on how Excel sorts the columns. The values are stored in
Universal Time format.
Doug M
Applications Engineer
National Instruments
For those unfamiliar with NBC's The Office, my icon is NOT a picture of me

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

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.

HOw do I fix the fact that ical jumped (almost) all my events post daylight savings time change an hour ahead?

A few weeks ago I noticed that everything past 3/8 was an hour ahead, and I assumed once daylight savings time changed it would all jump back. It hasn't, and I don't know how to continue scheduling events or if I should change them all. I read that (a few years ago) the suggestion was give it 24 hours to adjust??

I think this problem is more complex. Background - UK clocks went back at the end of October; the USA went back one week later. I am in the UK and my Outlook calendar contains appointments created in the USA.
Someone in the USA created a recurring appointment before any clocks went back. In Outlook everything is correct. The meeting times are the same each week except for the one week between the two clock changes when, quite correctly, the meeting shows up one hour earlier. When I sync with my iPhone, the meeting shows at the same time every week regardless - this is incorrect.
Someone in the USA created a recurring appointment in the week after the UK clocks went back but before the USA clocks did. Outlook correctly shows the first occurrence as one hour earlier than all the following occurrences. Unfortunately - and this is the really nasty bit - the iPhone shows ALL the appointments one hour earlier than they should be. The only one that is correct is the first one.
This is a nasty bug and something that Apple needs to fix.

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

READ THIS PLEASE : New technote crashing, Daylight Savings Time, Nov 4th time change in US.

http://www.adobe.com/go/kb402776
TechNote
Dreamweaver CS3 crashes after Daylight Savings Time ends
Issue
Adobe Dreamweaver CS3 crashes when working with certain PHP
or ASP files in
Code view or Design view after the clock goes back one hour,
when Daylight
Savings Time ends. The crashes only occur when selecting
certain lines in
Code view, or selecting certain objects in Design view. The
crashes only
occur in files that have PHP or ASP code, intermingled with
HTML code. The
crashes do not occur in Dreamweaver 8 or earlier (Ref.
229536).
Reason
The Dreamweaver CS3 WinFileCache-7A9586CB.dat file has been
corrupted by the
time change.
Solution
1. If Dreamweaver is open, quit the application.
2. Delete the WinFileCache-7A9586CB.dat file from the
Dreamweaver user
configuration folder. Note that on Windows, the Application
Data and AppData
folders are hidden by default, so verify that your Windows
Explorer folder
options are set to View Hidden Folders. The location of this
file is as
follows:
* Dreamweaver CS3 on Windows Vista:
C:\Users\[username]\AppData\Roaming\Adobe\Dreamweaver
9\Configuration
* Dreamweaver CS3 on Windows XP:
C:\Documents and Settings\[username]\Application
Data\Adobe\Dreamweaver
9\Configuration
3. Restart Dreamweaver.
Keywords
Code/Design view, Daylight Savings Time, Dreamweaver, crashes
TechNote Details
Last Update: 11-02-2007
ID: kb402776
OS:
* Windows XP, Windows Vista
Permanent Link:
http://www.adobe.com/go/kb402776
Alan
Adobe Community Expert, dreamweaver
http://www.adobe.com/communities/experts/

Alan wrote:
>
http://www.adobe.com/go/kb402776
>
> TechNote
>
> Dreamweaver CS3 crashes after Daylight Savings Time ends
>
> Issue
>
>
> Adobe Dreamweaver CS3 crashes when working with certain
PHP or ASP files in
> Code view or Design view after the clock goes back one
hour, when Daylight
> Savings Time ends. The crashes only occur when selecting
certain lines in
> Code view, or selecting certain objects in Design view.
The crashes only
> occur in files that have PHP or ASP code, intermingled
with HTML code. The
> crashes do not occur in Dreamweaver 8 or earlier (Ref.
229536).
>
>
> Reason
>
>
> The Dreamweaver CS3 WinFileCache-7A9586CB.dat file has
been corrupted by the
> time change.
>
>
> Solution
>
>
> 1. If Dreamweaver is open, quit the application.
> 2. Delete the WinFileCache-7A9586CB.dat file from the
Dreamweaver user
> configuration folder. Note that on Windows, the
Application Data and AppData
> folders are hidden by default, so verify that your
Windows Explorer folder
> options are set to View Hidden Folders. The location of
this file is as
> follows:
> * Dreamweaver CS3 on Windows Vista:
> C:\Users\[username]\AppData\Roaming\Adobe\Dreamweaver
9\Configuration
> * Dreamweaver CS3 on Windows XP:
> C:\Documents and Settings\[username]\Application
Data\Adobe\Dreamweaver
> 9\Configuration
> 3. Restart Dreamweaver.
>
>
> Keywords
>
> Code/Design view, Daylight Savings Time, Dreamweaver,
crashes
>
> TechNote Details
> Last Update: 11-02-2007
> ID: kb402776
> OS:
> * Windows XP, Windows Vista
> Permanent Link:
http://www.adobe.com/go/kb402776
>
>
>
Interesting, because on my PC that cache file is only in my
old DW8
folder, while this one is in my DW9 (CS3) folder:
WinFileCache-AD76BB20.dat
What's up with that?
E. Michael Brandt
www.divaHTML.com
divaPOP : standards-compliant popup windows
divaGPS : you-are-here menu highlighting
divaFAQ : FAQ pages with pizazz
www.valleywebdesigns.com/vwd_Vdw.asp
JustSo PictureWindow
JustSo PhotoAlbum, et alia

Fall Daylight time change & 9i

Similar Messages

Maybe you are looking for