Daylight savings and time zone

Hi. Working on an 8i database I need to determine in a function what is the current time zone, and if daylight savings time is running. I need to pass back how many hours to adjust. Does anyone have a suggestion?
Thanks.

I have finally found the solution!!! My account is set up as an Administrator, yet for some reason Illustrator was not opening with Adminsitrator permissions. I have to go into my startup menu, right click on Illustrator, and open as an administrator. Suddenly, everything works faster, smoother, and properly! I don't understand the reason behind this, but at least it is working proper now.

Similar Messages

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

DST(Daylight Savings) and EBS

Hi all
I'm running 11.5.10.2 in Australia and Daylight Savings will be finished this Sunday.
All the patches for DST have been applied on database, APPS as well.
I'm just wondering if there are more to do in APPS
such as bouncing Concurrent managers or Application Services, update profile options etc
Can anyone tell me about it?
Thanx in advance
Edited by: user12194104 on Mar 28, 2011 9:37 PM

Hi;
AFAIK if you prepared your db than you dont need to do something on apps tier, by the way what is your db version?Do you use ADI?
please also check below notes:
Diagnosing DST issue with eBusiness Suite 11i and Release 12 [ID 800420.1]
Oracle E-Business Suite Release 11i Technology Stack Documentation Roadmap [ID 207159.1]
Complying with Daylight Saving Time (DST) and Time Zone Rule Changes in E-Business Suite 12 [ID 563019.1]<< applicable for r11 too
Regard
Helios

Sales Office Master - Country, Region and Time Zone

Dear All,
In one of the Project, for some config-settings, I need to create Sales Offices. Here, Sales Offices is basically the Countries, to which business is happening.
For example,
Jordan
Mexico
Colombia
etc...
Now, while maintaining Sales Office records, System prompts for Sales Office Address. Initally, i maintained Country as per the Sales Office, for example:
For Sales Office Nepal, Country Nepal
For Sales Office Mexico, Country Mexico
etc...
Now, when i checked previously maintained entries in to System, I found that:
For Sales Office New Hampshire, Country India
For Sales Office California, Country India
etc...
When, I inquired about the same to concern Persons, within particular Organization, they are unable to explain, as these entries are maintained by Previous Implementation-Partner.
Can anyone explain, what entry needs to be maintained as Address - Country, Region and Time Zone, for International Offices? Is there particular logic for the same?
Best Reagrds,
Amit

Dear All,
Thanks for the Support, provided.
Let me explain, my scenario, in detail.
I am maintaining Profit Center, in Sales Order, based upon Substitution Rule.
For that, I have to maintain Profit Center, based upon Sales Area and Sales Office combination.
suppose, If my combination is:
1. if Sales Area is 10100107 and Sales Office is Colombia, then Profit center would be X
2. if Sales Area is 10100107 and Sales Office is Mongolia, then Profit center would be Y
Now, Important aspect is all Sales Organizations are maintained under Company Code ABC; and Company ABC is maintained under Country INDIA. Whereas, Sales Offices are both, Domestic, as well as International.
My queries are:
1. What effect has gone be made, if Sales Org is maintained under India and Sales Office, under some other country, in Sales Order?
2. Also, based upon Sales Office, System must pick the Transaction Currency, in Sales Order?
Best Regards,
Amit

Re: (forte-users) DateTimeData and time zones, I need amagictrick !

You might try externalizing as textdata whenever its passed between partitions.
kelsey.petrychynsasktel.sk.ca on 04/26/2000 03:45:28 PM
To: "Guylain Rochon" <GRochonInfluatec.ca>
cc: kamranaminyahoo.com (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: Re: (forte-users) DateTimeData and time zones, I need a magic trick !
I haven't done a lot of work with time zones, but I have some ideas that just
may work. If it is important for this object to pass in and out of time-zones
untouched by the destination try passing it by reference. The idea is that the
actual object will remain in one time zone. You may need to "anchor it down"
somehow where it resides (Make it private, READ_ONLY or ??).
Another thing to try is: If it is passed via a method set the mechanism as
"input". I believe this will stop the destination from changing it. (i.e. It
will receive it as input only).
Just some ideas. Good luck.
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
Guylain Rochon <GRochonInfluatec.ca> on 04/26/2000 01:15:47 PM
To: "\[FORTE\] Maling list" <kamranaminyahoo.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) DateTimeData and time zones, I need a magic trick !
Help, I'm drowning and Fort

I haven't done a lot of work with time zones, but I have some ideas that just
may work. If it is important for this object to pass in and out of time-zones
untouched by the destination try passing it by reference. The idea is that the
actual object will remain in one time zone. You may need to "anchor it down"
somehow where it resides (Make it private, READ_ONLY or ??).
Another thing to try is: If it is passed via a method set the mechanism as
"input". I believe this will stop the destination from changing it. (i.e. It
will receive it as input only).
Just some ideas. Good luck.
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
Guylain Rochon <GRochonInfluatec.ca> on 04/26/2000 01:15:47 PM
To: "\[FORTE\] Maling list" <kamranaminyahoo.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) DateTimeData and time zones, I need a magic trick !
Help, I'm drowning and Fort

Since loading mavericks my calendar posts events one hour late. That is, if mtg invite is for 9am it posts at 10am. my pc clock and time zone are correct.

Since loading mavericks my calendar posts events one hour late. That is, if mtg invite is for 9am it posts at 10am. my pc clock and time zone are correct.

Hey Armando Stettner,
Thanks for the question, and what a great question it is!
With time zone support on, you can edit an individual event and change the time zone for that event. This list will include options for your default time zones, UTC, and "floating" - the latter of which is what you are looking for. Floating changes the event to occur at the specified time, local time.
For information on changing an event's time zone, see the following resource:
Calendar: Change an event’s time zone
http://support.apple.com/kb/PH11531
I look forward to hearing how this works for you.
Cheers!
Matt M.

Daylight Savings Time and Time Zone Issue:

Howdy! Many of us woke up this morning to be dismayed to find that our iPhone was TWO hours behind instead of falling back one for the Daylight Savings Time adjustment, and were late for church. I have an iPhone 4S, with iOS 5...
I was working at that time of morning, and the initial switch went well. However, when I woke up, the clock was yet another hour behind. A little investigation showed that the Time zone had been changed to Denver (It was previously on Chicaco, and I live in Dallas.) I tried to select it to change it, and it wouldn't allow me. If I turned off the Set Automatically feature, then I could change it, but when I turned the Set Automatically feature back on, it would re-set the time zone to Denver.
I found another thread where they discuss this:
https://discussions.apple.com/message/16644669
To fix this, put in airplane mode, then back out again, then re-choose your correct time zone. If this doesn't work, then try turning your phone completely off and then on again. Thanks to 4n6doc for the tip!
The airplane mode trick worked for me: I turned airplane mode on, then off, then went to the Date & Time and set my time zone to Dallas, TX while the Set Automatically was off. When I turned the Set Automatically back on, it changed Dallas to Chicago, which is what every iPhone iOS I've ever had has done.

Hi,
Yes this is a correct way to fix the issue. One thing however, how did you set the timezone? For correct daylight saving handling, you'll have to use the long version, like America/New Yorw, NOT GMT-5 (for example).
regards,
~ Simon

Site synchronization and daylight savings/standard time

The familiar problem of Dreamweaver not accounting for the
change from Daylight Savings to Standard time persists with CS3.
This only shows up on Windows machines. Windows (tested with both
XP and Vista) maintains all file times in UTC, and changes the
locally displayed time based on the time zone. The remote servers
are all Linux boxes running Apache. DW connection is through SFTP.
Dreamweaver appears unable to figure out the local time stamp
offset imposed by Windows. After changing from Daylight Savings to
Standard time, Check In operations produce a message that all
remote files are dated an hour later than the local files. This is
the opposite behavior one sees in the Spring, when the change from
Standard to DST has Dreamweaver believing all remote files are an
hour out of date.
In the past I have manually changed the file modification
times on all files for every site. Given that this comes to several
hundred thousand individual files, it is a pain. Searching yet
again for a method to convince Dreamweaver to correctly interpret
the file timestamps produced little more than Google's listing
thousands of search hits for other folks mentioning the same
problem.
It made no difference which timezone the server was in (or
set to) relative to the PC running Dreamweaver. The timezones could
be identical or different -- DW always complained the remote files
were an hour later than the local ones. I changed timezones on both
the server and the local machine. No help. Neither was rebuilding
the site cache nor manually deleting the WinFileCache*.dat file. I
also tried manually editing a dwsync.xml file in a _notes folder to
see if I could alter DW's view of the world. Again, no such luck.
Making matters far worse, however, Dreamweaver complains
about file time differences in newly modified files as well. A
standard Synchronize command produces "Resolve" errors for every
newly modified file that is not first checked out from the remote
site using DW, saying both local and remote versions have changed
since the last sync. Running "Check In" on a newly modified file
that was not explicitly checked out (e.g. an image or other binary
file) does nothing, as DW sees a timestamp discrepancy. These files
must first be Put to the site, with the corresponding DW error
dialog, and then be checked in.
I am suspecting the problem stems from Dreamweaver's lack of
support for the
MDTM
command. Many other products, ranging from commercial packages
such as WS_FTP and Microsoft's Expression Web, to $30 shareware
programs such as Beyond Compare, to freeware programs including
WinSCP all correctly interpret Windows timestamps as well as
preserving the correct time upon file uploads. Is there any
solution other than changing the timestamps by an hour on every
file or getting every file from all sites to satisfy Dreamweaver's
belief that the files are all an hour newer than they actually are?
The former is a non-trivial task given the sheer number of files to
change; the latter is a bandwidth PITA for ~90GB of data.
Message to Adobe: Please fix this problem. It hits users
connecting Windows local machines to Linux servers twice a year.
Your competitors as well as shareware authors have sorted this
matter out.

Ethan H wrote:
> The familiar problem of Dreamweaver not accounting for
the change from Daylight
> Savings to Standard time persists with CS3.
Yes, it's a bug, and it's a PITA.
> Message to Adobe: Please fix this problem.
Message to Ethan H: This is a user-to-user forum. To get the
message to
the right people in Adobe, submit a bug report:
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
Yes, I'm sure that Adobe knows about the problem without you
going to
the effort to submit a report, but the bug report/feature
request form
is how the development team assesses its priorities.
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS3" (friends of
ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

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

Daylight savings and backup exec

I haven't had this problem before, the OS and patching hasn't changed,
here are the configurations and symptoms.
OS platform is NW 6.5 OES SP6. Running the time command shows the
correct time. However the Symantec Backup exec software 9.2 rev 1391 is
exactly 1 hour behind. This stems from daylight savings. The backup
software resides on a cluster node but is not cluster enabled. The node
and software have been restarted but the time is still incorrect.
This is a very strange behavior, has anyone felt this sting?
Cheers,
CB

LinuxNewbie1,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your problem been resolved? If not, you might try one of the following options:
- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your Novell Product Support Forums Team
http://support.novell.com/forums/

ISE 1.3 - Multiple ADs and time zone

Hi all,
I have a question regarding time zone settings, AD interaction and ISE PSN.
Assuming the following deployment:
- ISE distributed deployment with 3
- Each PSN is joined to a AD at a specific site (example: one in USA, one in Europe, one in Asia)
If the DCs at each site have different clocks (same UTC time source, but different time zone) I'll probably run into issues, right?
Because:
First fact:
Set correct time and timezone. Kerberos needs to be within 5 mins of the DCs you use
(Source: Cisco Live Breakout BRKSEC-2132)
Second fact:
Also, it is important to have all the nodes in a single ISE deployment configured to the same
time zone. If you have ISE nodes located in different geographical locations or time zones, you should
use a global time zone such as UTC on all the ISE nodes.
(Source: ISE 1.3 admin guide)
So the first recommendation is, that the ISE PSN has the same clock as the local DC - on the other hand the time zones in one distributed deployment should be the same on all nodes.
What to do?
Big thanks in advance!
Johannes

Not yet - In my lab environment I'm not having a multi-tier CA (and I'm not very good when it comes to Microsoft Active-Directory stuff :) )
Edit:
I did one very limited test in my testlab. In my testlab I'm having one DC and two ISE appliances.
Test1: I removed the AD join of the ISE appliances. The ISEs are configured for CET and I reconfigured the time zone of the DCs to UTC-7:00.
ISE and DC clocks are correct (synced against NTP), but the absolute time is different due to different time zones.
Then I joined the ISEs again - and it worked.
Test2: I removed the AD join of the ISE appliances. The ISEs are configured for CET and I configured an incorrect static time to the DCs (some weird time).
ISE join won't work
Error Description: Clock skew detected with active directory server
Support Details...
Error Name: LW_ERROR_CLOCK_SKEW
Error Code: 40087
Perfect - different time zones are obviously ok...

ICal and time zone stamps?

Apologies that this is long. It's three questions about trouble I've recently encountered using iCal.
I imported 80+ appointments into iCal from a .ics file created by Oracle Calendar.
1. The .ics file did not contain any time zone info, and iCal associated each of the imported appointments with GMT, despite the Mac's zone set to "Denver" in the Date & Time preference pane and iCal's time zone set to "America/Denver". Why doesn't iCal associate unassigned appointments with its own time zone?
2. Each of those appointments appeared in iCal at the correct local time, despite being associated with GMT. That is, with iCal's zone set to "America/Denver" I would have expected an item imported as, e.g., 10:00 GMT to show up at 17:00 in the iCal window. But none of them did--they all appeared as if they were MST, but with GMT stamps, and I don't understand why.
3. I didn't actually find out these items were associated with GMT until after I synced with my Palm Tungsten E. All of the items imported as GMT were shifted 7 hours on the Palm. So I went back to iCal and for each and every one of the imported appointments I changed the time zone to "floating" and then "America/Denver". (If I went straight from GMT to MST the appointment jumped 7 hours back in time, and I got tired of this.)
After that process, every event in iCal was associated with MST. I then synced with the Palm and found that, to my surprise, the imported events still showed up on the Palm as if they were GMT, i.e., shifted forward 7 hours. I should add that I didn't merge, I told the sync conduit to erase the Palm's contents.
Back to iCal. I used "Back up Database..." and "Revert to Database backup...", then sync, telling conduit to erase Palm's contents. No change.
Back to iCal. I select one of the troublesome events, "cut" it to the clipboard, and then paste to bring it back. After a sync that one event shows up correctly on the Palm, i.e., as MST as intended.
The question at the end of a long #3 is, if an event is imported with the wrong time zone stamp, why does it retain that stamp despite being manually changed to a different time zone?
I know the knowledge base has an article on incorrect time zone stamps, and that a possible fix is to export the entire database and then import to a new calendar. I didn't find this out until recently, and it doesn't address iCal's behavior so much as provide a workaround.
PowerMac G5 DP 2.0 GHz Mac OS X (10.4.4)

After looking more closely at the .ics files exported by Oracle Calendar I see that events are exported as if they were GMT; iCal is, indeed, showing the appointments at the correct local time. This makes my first two questions irrelevant.
However, question #3 still remains: why or how does the original GMT stamp persist after manually setting an event's time zone to local time, "America/Denver"?

ICal and Time Zone

I have a problem with iCal.
In iCal time zone shows as a "CENTRAL EUROPEAN TIME" which is wrong. There is the an option to change (Other) that but it does change anything. When i try to change it goes back to "CENTRAL EUROPEAN TIME" again.
On the other hand In my preferences, my time zone shows as "WESTERN EUROPEAN SUMMER TIME" which is correct.
When i send an iCal, the recipient receives two hours in the invitation.
I can i solve this problem?
greetings,
Paulo

It will send in the timezone of your location in preferences. You can verify this by sending an appointment to a web mail account, and then downloading the attached ics file and opening it with text edit. You'll be able to see exactly what Timezone it is sending.
Message was edited by: fishdan

ICal events and time zone change

Has anyone scoped out what happens to iCal events when your MBP moves between time zones and automatically changes the date and time settings? In general, I'd like my calendar events to be fixed at the time in the time zone where they are supposed to occur, and not where the MBP is, but of course I'd like the MBP to be telling me the time where it actually is. I don't think iCal does it this way, but I'm not sure how it handles time differences. Anybody know?

In iCal preferences, there is a check box for "turn on time zone support." If you leave it unchecked, iCal will automatically adjust to your current time zone and move the events forward/back by the appropriate number of hours. If you check "turn on time zone support" a drop-down menu will appear at the upper right of the iCal page allowing you to select the time zone you wish to view. In this mode, iCal does not automatically move the events unless you select a new time zone manually. Does that make sense?

Calendar and time zone issue

When i get an invite from our west coast office for meeting at 1 pm west coast time and i accept here in east coast time it ends up at 1 pm east coast time instead of adjusting for the three hour difference. any suggestions?

Me too with the same problem. If I move to a different time period (say from Week to Day) after changing the displayed time zone, it does refresh.

Daylight savings and time zone

Similar Messages

Maybe you are looking for