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

Similar Messages

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.

Daylight Savings Changes 2007

Daylight Savings time will be altered in 2007 as seen in http://geography.about.com/cs/daylightsavings/a/dst.htm
Is Coherence certified to handle these changes? We have already found issues in the OS and JDK that need to be patched.

Coherence will correctly handle daylight savings changes once the JDK has been patched.
Without the JDK patch, only the Coherence logging function will be incorrect, in that the logged messages will reflect the incorrect (unpatched) "timezone".
Coherence has very careful handling of "wall clock time" functionality to avoid being impacted by network time daemons, system clock irregularities, time zone shifts, etc.
Peace,
Cameron Purdy
Tangosol Coherence: Data Grid and Clustered Cache

Any imapct on MS JVM due to Daylight savings changes in 2007

Is there any imapct on MS JVM due to the Daylight savings changes in 2007.

I don't know. What did Microsoft support tell you when you asked them?

When time zone support is on even when I am on Jerusalem, when i create an appointment the time zone for the appointment is immediately changed to Gaza and even when I change it manually it returns to Gaza.

I have a 4s iPhone on IOS 6.0.1 with an Israeli Cellular provider.
I use Gmail services an exchange to sync my colander contacts and mail.
When the time zone support is set to ON in the Settings->mail, Contacts, Calendars->Time Zone Support
The time zone is showing Jerusalem (I am located in Tel-Aviv)
When I create a new Appointment, It Immediately changes the time zone of the appointment to Gaza.
Even if I change it back to Jerusalem it changes back to Gaza every time.
Only when the time zone support is set to OFF in the Settings->mail, Contacts, Calendars->Time Zone Support
The time zone in Gmail is ok and does not appear on the iPhone. (This is ok)
Dose any one know how do I make the iPhone not change the time zone to Gaza? And still keep the time zone support on?
TNX

they are not always on the same time due to daytime saving time changes twice a year in Israel which are not syncronized with any changes in Gaza, Beirut, etc.

Problem caused with appt times by changing calendar time zone support?

I've got a 30Gb iPod Touch, version 4.0.2.
I've always kept the Settings' Date & Time timezone for the correct location, but it was only a while back that I realized that there was also a Time Zone under the Settings, Calendar, and so I changed it so that it was correct (it was previously set to Kabul, AF time, and it was then changed to Ottawa, ON time).
I'm thinking that this may have messed up all my future appointments, as my appointments have been switched to midnight or somewhere near it, for the day prior to when the appointment was supposed to have been. I can't think of anything else that would be causing this, and didn't see this exact problem occurring for anyone else when I did a search of the discussions.
Does anyone have any idea as to why this is happening and what I can do to set it right?

Hi Cindiii,
Time zone support has often been a point of contention and confusion for many users. Unfortunately, there is no simple fix at the present time. Do you have any idea as to why you touch was set to Kabul? Did you buy it new? If not, perhaps the last user had it set to this time?
In any case, Calendar does allow for its own time zone settings. This is to allow the user to create events for his/her home time zone while traveling. Even if your system time zone reflects the current time zone that you are in, appointments added to Cakendar will show up in the time zine that you choose based in the time zone you set in the Calendar settings.
This definitely sets up conflicts if you are trying to schedule an appointment that is outside of your home time zone. Now that you have switched the time zone in your Calendar settings to your home time zone, there is nothing you can do about the events already created. As I see it, you have only two options:
1. Change the time zone back to Kabul time and view your events as though they were your local time, or
2. Leave the time zone in the Calendar settings to your home time zone and either time adjust the events in your head (knowing the time difference), or manually changing them to the correct time one by one.
I'm sorry this doesn't provide you with a magic solution, but I really don't see any other alternatives.
Mac

Alarm turned off after daylight savings change?

Hi. I woke up late this morning. I know I set my alarm last night. Last night was the change to daylight savings (forward one hour). Ok, I'm human, so of course being asleep, I can't be 100% sure I didn't turn it off without waking... we all have done that right? :P But I'm fairly certain I didn't, and am wondering if this may be a software glitch. I don't want to wait 6 months to find out when it changes back.
iPhone 4 fully updated. Alarm set to 5:30am

It seems that because of the structure and communication of Apple corporation, the Apple telephone support staff may not necessarily know any more than a thoughtful user, and almost certainly will know less about this particular alarm issue than a user who peruses these forums. For example, they didn't know that turning off Time Zone Support is another way to temporarily solve the problem (as an alternative to changing Set Automatically to OFF) - something I learnt from an Apple discussion.
This problem was raised in these discussions in June of this year for users in Lithuania and in Sri Lanka. It was New Zealand's turn in late September, and Australia's turn on Sunday. My guess is that Apple will scramble to fix the issue before it hits USA users in November, but why rush until then, when it's only users from other parts of the world (non-Americans) being affected?

Why is iCal Time Zone Support hidden?

Last week my wife sent me an iCal appointment for 2pm but I received it as 11am. On checking her iPhone she found the same time, 11am. We had both been overseas recently. On our return we had reset our time zones on our iPhone's and laptops to Auto so no problem there. Obviously we were very puzzled.
I then checked the Apple support page and found a lot of people had the same problem with Mountain Lion although I'm running Mavericks.
What I did discover was that in iCal > Preferences> Advanced is hidden a button called Time Zone Support.
Why put it there? And why is it off by default?
We turned it on on my Mac Book and hers then switched it off then on again on our iPhones and low and behold the appointment times changed to 2pm on all our devices.
I don't understand why changing time and date settings or having them on Auto shouldn't adjust all native apps and hiding the setting in advanced preferences just seems ridiculous.
Maybe that's just me?

I'm not sure how putting something in the user Preferences for an app hides it, but...
And why is it off by default?
I got into an argument with someone about using time zones in Calendar. He only wanted the times to show up as local times regardless of which time zone was selected and what time zone had created the event. I think he actuall missed some appointments when travelling overseas. His assistant had set up the appointments, and when he looked at them before he left, they were listed as late in the day because he was looking at his current time zone.
So, I guess that is why it is off by default.

Time zone support help: how do I enter an event and have it keep that time regardless of time zone?

I consistently enter events in one time zone, because that is just easier. I would prefer it KEEP them as entered, not revise them as I travel. IE, I live overseas and constantly travel. It is very difficult to keep track of my schedule if I must always calculate the time zones when entering or viewing events. How do I set it up to leave them as entered, even as I travel, without changing the ipAd clock to stay in one time zone?

Hi karlsf!
It sounds like you may need to adjust your time zone support settings. An article about doing this can be found here:
iOS: How to adjust Time Zone Support for calendars
http://support.apple.com/kb/ht4576
Thanks for using the Apple Support Communities. Have a good one!
-Braden

HT4576 "Time Zone Support" in Calendars should be renamed to "Override Time Zone Support"

So, I live on the East coast and notice, while on a trip just outside Cupertino, that my iPhone Calendar wasn't updating to the the local time, even though my iPhone had correctly updated to PST.
Finally, at the end of my trip, oh so nigh to Cupertino, I find out that my Calendar's erroneous display of time was due to the "Time Zone Support" configuration option.
This is a GROSS misnomer.
iOS requires the specification of a timezone - else the time would be set arbitrarily and would waste the time (NTP) service provided by the cellular provider.
Thus, the "Time Zone Support" option under "Mail, Contacts, Calendars" should be relabeled to "Override Time Zone Support" AND the ability to assign an event to a time zone should always be available (though defaulting to the current time zone - unless a 'Default Time Zone' configuration option is added).

The behavior you are seeing is actually inherent in most calendar apps -- the deal is that you are telling your calendar when something happens, not what time. Our company writes a calendaring+task management app for iPhone called Pocket Informant - we get this same question on occassion, so I wrote up a Knowledge Base article discussing some details (keep in mind - this article discusses some features specific to our app that you won't find in iCal/Calendar on MacOS X):
http://webis.kayako.com/Knowledgebase/Article/View/123/0/why-do-the-times-change -on-my-appointments-when-i-travel-to-a-different-time-zone
In iCal/Calendar on MacOS X, when you turn on Time Zone support, you then get to choose the time zone that you are entering your appointment for. This helps you not have to do the "time zone math" in your head. Thus, if you are in CST and want to set up an appointment for 6pm PST, you can choose PST in the event editor as you enter 6pm. Note that while you are in CST, your event will display in your calendar at "CST time" (8pm), but when you fly out to PST, it will show the "correct" PST time.
While iCal/Calendar supports "floating time zones", I personally would caution against using them for everything (I mentioned a few reasons why in the above kbase article). Use those for events that truly are "time driven" rather than "point in time" driven (such as "I want to go jogging every morning at 5am no matter what time zone I'm in).
Hope that helps some!

Getting the time zone support right

When I take an international trip I can never seem to get this right, and calendar events go slip-sliding all over the place.
I have tried by time zone support on and off, but still previous events seem to get displayed wrong no matter what I do.
Currently I'm in Tokyo. Next Friday I'm going to St. Louis for a couple of months. I have a customer call on June 6th at 10 am central time. I just added it to my calendar by entering "Call with Coaches on June 6 at 10 am CDT" (see screenshot) and it created this event which correctly shows it taking place on June 7th Japan time. And I added a note about the actual time just in case.
So how should I have it set so when I am in St. Louis it shows up as June 6 at 10 am?
And what will happen with all my other events where I typically don't specify a time zone?
Thanks,
Doug

Hey Doug Lerner2,
Thanks for the question and superb details. I can understand how confusing Time Zone support can sometimes be. In my experience, everything is going to relate back to the main Time Zone Support drop down menu at the top left of the Calendar. This is the easiest way to quickly switch the Time Zone you are viewing.
Once you travel to St. Louis, simply switch the time zone of your calendar (if it had not automatically switched) to see all of your events in the local time zone (including events that don’t specify a time zone). So if you had your event set for June 6th at 10am CST, once you switch the Time Zone to central time you’ll see that that event is displayed correctly. All of your events that were created in Japan will move to their respective times, and you can also have “Floating” events that will ignore the time zone, and always be at that set time.
For more information, see these resources:
Calendar: View all your events in a different time zone
http://support.apple.com/kb/PH11534
Calendar: Change an event’s time zone
http://support.apple.com/kb/PH11531
Thanks,
Matt M.

Time Zone support

I understand the basic gist of time zone support as it is pretty straight forward, but I'm constantly finding myself confused when I use time zone support when I travel. For instance, I use EDT and sometimes put events in my calendar that I know I'll have while I'm traveling. If I put an event in my calendar for 2:00 pm because that is when the event is supposed to start, but the event is taking place in California, the event shows up in my calendar at 11:00 am and I get all confused as to when my events are actually supposed to start.
Is the best policy to figure out what the adjusted time is supposed to be and make the adjustment beforehand, or is it best to turn off time zone support? It gets really confusing when trying to add events to your calendar when the events take place in different time zones.
Any thoughts on this subject would be greatly appreciated
Mac

Simple answer is that the events should not be moving if the setting has stuck, so it's probably a preference file that has been corrupted.
Do you see the time zone at the top right of the iCal window?
If it's there even though you have unchecked the option in preferences, it might be worth going into preferences and rechecking, quitting preferences, going back in and unchecking.
If that fails to get rid of the zone in the window (or it wasn't there in the first place), you probably need to trash the preferences file for iCal:
Quit iCal.
Look for this file ~/Library/Preferences/com.apple.iCal.plist [That's in the Preferences folder of the Library folder of your home folder in case you don't understand the notation.] Drag it to the desktop - or somewhere convenient (so that you know where it is and can put it back if iCal gets screwed-up).
Restart iCal.
This should start iCal in the default mode - which is with Time Zone support off. You will notice that the position and size of windows, default view (month, week, day), etc have also been reset - so you will need to arrange them to your liking and check that the preferences that you need are set correctly.
You should now be able to change time zone without everything moving. If it works, you can trash the file you moved to the desktop.
If this doesn't fix your problem, you can at least get back to where you started by:
Quitting iCal.
Dragging the original .plist back over the new one.
Restarting iCal.
* Make sure you back-up your data before doing anything. However, I just tried this with my own iCal and it all worked 'as advertised' *

Cannot completely turn off time zone support in the iPhone calendar

In iOS7 it was possible in settings to turn off time zone support in the calendar. (This is not the same as having the date and time of the phone automatically change to current time zone which is generally what one wants and is not affected by calendar time zone support.) The problem in iOS8 is that Time Zone Override is not the same as Time Zone on/off. Here is an an example.
1) you live in Chicago and central time is your "home" time zone.
2) you find out about a meeting in New York at 1:00pm next week. You want to add the meeting to your calendar. If you add it at 1:00pm, when you arrive in New York (and change time zones), it will change the meeting time to 2:00pm.
Time Zone Override does not turn off the time zone calendar support. It provides two different views (time in current time zone and time in home tine zone). But time zones are irrelevant when I am scheduling an event at a known time. (Time Zone Override ON seems to work only if you are out of your home time zone and schedule something in your home time zone. But this is almost never what I encounter since I am usually at home, and need to schedule an event outside my home time zone.)

It would seem that way. But with "time zone support" on, you'll simply view your events "as if" you were in a certain time zone.
Example: I create an event in California for 6pm. ( A "California event") If I turn "time zone support" on, and select my time zone as Los Angeles, nothing changes. But if I select Oklahoma city, the time WILL change to 8pm, because it assumes I need to view a "California event" in Central Time.
"Time Zone Support" was created for people that have phone conferences in different time zones. The feature allows one standard time to be used in the calendar, and anyone outside the time zone can use "time zone support" to read it in thier respective time zone.
I'm saying this feature is trying to complicatedly simplify the calendar. I can use the organ between my ears to assume the correct time zone. And having to dig into my preferences in order to view my events correctly is completely insane.
All I want is to create an event, set an alarm, and not have to EVER worry about it changing.
I assumed that turning "time zone support" off would accomplish this as it did in the past. But the calendar STILL REMEMBERS WHERE AN EVENT WAS CREATED. So if the time zone ever changes, it will try to view the event according to the time zone you are currently in.
iCloud does the same thing. When you set your time zone on iCloud, it will view an event according to THAT time zone. If you are in Central time and create an event, your iCloud calendar better be set to Central time or else there will be a descrepancy between your phone calendar and your iCloud calendar.
I just want to turn off "time zone support" COMPLETELY.

Change time zone of many events

I've moved time zones. How do I change the time zone of all my extant events to be in the new time zone?

Dr. Pantzo,
I will presume you are using Snow Leopard.
Use iCal>Preferences...>Advanced>Turn on time zone support.
Open System Preferences...>Date & Time>Time Zone: either check "Set time zone automatically," or pick your closest city.

Turning off Time Zone Support

Hi,
I have recently moved countries which are 8 hours apart.
I have had Time Zone Support turned on in iCal and my iOS devices. I also use Google Calendars.
If I try to switch time zones, all my appointments move by 8 hours. I don't need to know what the time is in other zones, I suppose what I want is the "floating" time zone.
I have tried to export and reimport my calendars but the time does not change correctly. Do I need to edit the .ics file in some way?
Thanks!

Hi,
If you need it I have a script to move all events in a calendar by a number of hours. See the script Offset iCal Events here.
Best wishes
John M
<hr />As I sell software on my site and ask for donations, the Apple Discussions Use Agreement requires that I state that I may receive some form of compensation, financial or otherwise, from my recommendation or link.

2007 US Daylight Savings change time zone support in JDK 1.3

Similar Messages

Maybe you are looking for