Time Zone Bugs In 10.10.2

I still have time zone troubles in Apple Calendar.
I have a few events that were sent to me in Outlook for an 11:00 AM PST start time that are showing in Calendar as starting at 11:00 AM CST. On my iOS devices (running the latest versions) they appear properly as 11:00 AM PST start times. Seems like there's a trouble with the Mac version somehow.
Happy to send screen shots if you'd like, though I can't figure out how to attach them to this discussion thread.

TThis seems to be a problem with third party plugins. You should contact Crumble Pop and Pixel Films to see what's happening.

Similar Messages

So is there a fix for this Time Zone bug?

apple, is there a fix to this Time Zone bug in Calendar?

You are not talking to Apple, just other Apple users. If you are experiencing something you think is a bug, you will have to describe it or reference some description. I am unaware of any specific Time Zone bug.

How to escalate Time Zone bug in iPhone Calendar to Apple?

Hi, does anyone know how to escalate a bug in the iPhone calendar software to Apple?
Time Zone support on the iphone which causes calendar items created in location "Kuwait" to be saved as "Gulf Standard Time" and not "Arabian Standard Time", which means that they arrive one hour out of sync in iCal.
To replicate the problem:
1. Turn on time zone support in both the iPhone and iCal
2. Set the location to Kuwait on both
3. Create an item in the calendar on the iphone
4. Allow it to sync over Mobile Me
5. See that it turns up 1 hour out in iCal
6. Open the event in iCal and notice that it is set to "Gulf Standard Time" and not "Arabian Standard Time"
The workaround is to turn the time zone on the iPhone to Riyadh, Saudi Arabia, which apparently is correctly matched to "Arabian Standard Time"
Thanks
Giles

There's the iPhone feedback page http://www.apple.com/feedback/iphone.html

Time zone bug in Belle browser

My Nokia 700 running Belle 113.020.1506, browser version 8.3 has a bug with time zones.
Any Australian East Coast time zone with DST offset (Hobart, Canberra, Melbourne, Sydney) has the browser report a GMT offset of 34, which is invalid. The correct value should be 10. This causes some mobile websites not to work.
Go to http://grega.co/time.html - this should return
Timezone: GMT+1000 GMT Offset: 10
This works OK on Opera Mini on my phone, but the Nokia browser returns a GMT offset of 34

There's the iPhone feedback page http://www.apple.com/feedback/iphone.html

Nokia 5800 time zone bug error

i have a nokia 5800 v.31.0.008 and in the time zone there is a bug in the Greece option, where it shows GMT +3:00 Greece. but in fact it's GMT +2:00 Greece. can nokia fix this in the next update?
Greece Nokia X6 RM-559 v40.0.002

go to this link and describe your problem there. http://europe.nokia.com/A4577231
Greece Nokia X6 RM-559 v40.0.002

Time Zone bug with 1.0.5.2304

I've noticed a problem with time zones in the latest version of the PlayBook OS. When you set the time zone to Saskatchewan it will display the correct time on the Date and Time page but the time that shows up in the status bar is one hour later. Anyone else seeing this?

Check this KB article, please - http://www.blackberry.com/btsc/KB27262
Regards,
Karim A. Harb

Time Zone Bug

Hello,
I recently purchased the new iPhone 4S.
When trying to set up the time zone, there are no options available for my state in Brazil. Actually, there are only limited options for cities in Brazil (currently there are 6 time zones for: Ferenando de Noronha, Rio Branco, Rio de Janeiro, Sao Paulo, Recife and Brasília. However Brazil contains 16 zones, according to the tz database.
There are no options available for my current time zone (I'm in the state of Mato Grosso - capital Cuiaba with 3.1 million people). I can't use a similar time zone from another country because we have daylight saving time during the summer. I would like to suggest apple to fix this issue, since there are other states in similar conditions and it's a very simple fix.
I would like to also ask if there are apps in the apple store to fix this issue.
Thank you,

setings > general > date and time, turn auto off then back on, make sure that you are connected to wifi when you do this

Automatic time zone wrong, automatic time zone wrong

Has anyone at Apple figured out a fix for the "Automatic Time Zone" bug?
Up until about a month ago, my phone (4, 16 gig) was working fine. Now it won't recognize any new time zones, and I have to set them manually. It's rather annoying.

You can run Repair Disk from the Restore Partiton your HD. Restart the computer, when you hear the startup tone choose the Restore Partition and then open Repair Disk. However I'd be surprised if that has anything to do it with it. You should run Repair Disk Permissions at least 2x, and then if you want run Repair Disk. Then restart the computer in Safe Mode to clear some caches. Then restart normal and check the Time Zone.
I also suspect you don't have iCloud setup correctly. You should check in Address Book preferences and see if you have duplicate accounts, I suspect you do. If I'm correct that would create duplicate entries.

Apex 4.1 bug? Application language derived from Session changes time zone

I have created an application in Apex 4.1 and in the "Initialization PL/SQL Code" for the session (what used to be called the VPD section) I have the following code:
begin
execute immediate 'alter session set time_zone = ''+01:00''';
end;This works as expected, UNLESS the "Application Language Derived From" (under "Edit Globalization Attributes") is set to "Session", in which case the session's time zone is also affected (and not just the language, as one would expect).
This can be seen in the following simple example, which runs the above code to set the time zone, and has the language derived from "Session":
http://apex.oracle.com/pls/apex/f?p=38595
This shows
sessiontimezone = -05:00Even though the session's time_zone has been explicitly set to +01:00 with the ALTER SESSION statement.
Experimentation with the URL shows that if a p_lang parameter is passed, with a valid language identifier, for example:
http://apex.oracle.com/pls/apex/f?p=38595&p_lang=de
then the time zone is affected (showing -05:00 instead of +01:00).
However, if an INVALID time zone identifier is passed:
http://apex.oracle.com/pls/apex/f?p=38595&p_lang=xx
then the session time zone is CORRECT according to the ALTER SESSION command:
sessiontimezone = +01:00If I change the "Application Language Derived From" to something else than "Session" (for example, "Browser" or "Item Preference"), then the timezone is also correct (ie follows the ALTER SESSION command).
Running the page in debug mode confirms that the time zone is being set after my VPD/initialization code has been run:
0.01585     0.00146     ...Application session: 1671806996734123, user=nobody     4
0.01731     0.00144     ...Execute Statement: begin begin execute immediate 'alter session set time_zone = ''+01:00'''; end; end;     4
0.01875     0.00065     Session: Fetch session header information     4
0.01940     0.00073     SESSION Language (nobody): wwv_flow.g_browser_language=en maplang=en     4
0.02013     0.00059     alter session set nls_language="AMERICAN"     4
0.02071     0.00043     alter session set nls_territory="AMERICA"     4
0.02114     0.00094     NLS: CSV charset=WE8MSWIN1252     4
0.02208     0.00111     ...NLS: Set Decimal separator="."     4
0.02318     0.00062     ...NLS: Set NLS Group separator=","     4
0.02380     0.00063     ...NLS: Set g_nls_date_format="DD-MON-RR"     4
0.02443     0.00091     ...NLS: Set g_nls_timestamp_format="DD-MON-RR HH.MI.SSXFF AM"     4
0.02534     0.00066     ...NLS: Set g_nls_timestamp_tz_format="DD-MON-RR HH.MI.SSXFF AM TZR"     4
0.02600     0.00050     ...Setting session time_zone to -05:00     4
0.02650     0.00065     Setting NLS_DATE_FORMAT to application date format: dd.mm.yyyy     4
0.02715     0.00056     ...NLS: Set g_nls_date_format="dd.mm.yyyy"     4
0.02771     0.00055     ...NLS: Set g_nls_timestamp_format="DD-MON-RR HH.MI.SSXFF AM"     4
0.02827     0.00057     ...NLS: Set g_nls_timestamp_tz_format="DD-MON-RR HH.MI.SSXFF AM TZR"     4
0.02884     0.00230     NLS: Language=en     4
Conclusion: It seems to me that when the LANGUAGE is set to be derived from the "Session", this also, as a side effect, alters the session TIME ZONE, which must be a bug... ?
- Morten
http://ora-00001.blogspot.com
Edited by: mobra on Sep 24, 2011 7:14 PM

Hi Arie,
When you are setting the language to derived from session you actually declare that you are working in a dynamic environment – per session – and not in a static one. Using the Initialization PL/SQL Code is very static as the same code is executed for every database session.I was using a fixed time zone value in the ALTER SESSION to demonstrate the bug/problem... in real life, the actual time zone is derived dynamically based on a user profile stored in the database.
APEX 4.0 introduced the Automatic Time Zone under the Globalization tab. By default it’s set to No but setting it to Yes will allow you to use your local time zone (as derived from your browser) with whatever language derived setting you choose, including per session with the *&p_lang* parameter.The key point is that LANGUAGE has nothing to do with TIME ZONEs, and vice versa. People speak English (and Spanish, and French, and Chinese for that matter) all over the world. You cannot determine a user's time zone based on the chosen language.
You're telling me to enable "Automatic Time Zone" to work around an unwanted side effect from changing the language setting. Sorry, but that just sounds like bad advice to me.
If you want to use session derived language, however the local time zone settings are not good for you, you can still change them with a Before Header and After Submit PL/SQL processes and an appropriate alter session statement, on a per page base. The APEX engine will not ignore a page based session setting.Why should I have to do this for every page when the "VPD" Section (now called "Initialization PL/SQL Code") is made for this purpose?
If you look at the help text in the Apex builder for that section, it actually says that:
The code entered here need not pertain to VPD/FGAC and may not be related to security at all.
Any code that needs to be executed at the earliest point in a page request can be placed here.
For example, the following code sets the database session time zone for every page request:
BEGIN
   EXECUTE IMMEDIATE 'alter session set time_zone = ''Australia/Sydney'' ';
END;So I hope the demonstrated behavior is not intentional, but a bug, and I'm hoping Joel sees it the same way.
- Morten
http://ora-00001.blogspot.com

ISE 1.2 Time Zone

Hi Community!!
I have a ISE 1.2 pair, v9 patch installed and sychronized. Recently our time zone changed to summer time which is one hour later. In the CLI I can see that the reference is sent by NTP and the clock has changed but in monitoring I can still see that there is an hour difference from real time.
I read in Cisco official documentation that time cannot be changed on ISE or else it will become unusable but the logs are not being timestamped correctly and also the time the RADIUS request are made by NAD vs the time they are recieved by ISE have one hour difference.
Is there a way to solve this? it seems to be prone to any kind of unexpected behaviour when we are least expecting it.
Thank you!!

Hmm, this is very strange and it almost seems like a bug with ISE. I would recommend that you contact TAC and have them check this out.
The reason I think that it is a bug (Related to the timezone) is the fact that the base OS (Cent/ADE OS) appears to be running fine and keeping track of DST (Day light savings) but the actual application (ISE) installed on Cent is not.
I am far from NTP or Linux expert but I don't believe that NTP pushes/honors timezones. I think NTP just synchronizes the clock while timezones/DST is controlled locally.
If the issue is not a bug, it is perhaps due to selecting the incorrect timezone. I have never done a deployment outside of the US and the UK so I am not familiar with timezones in Chile. However, if we take Eastern Time Zone for example. I had to make sure that I select "EST5EDT" in ISE and not just EST. If I simply selected EST then DST was not observed and made things ugly :) The same applied for Pacific timzone where I had to make sure that I select "PST8PDT" With all of that being said, I checked the CLI in ISE and I don't see any Chile related timezones that would indicate DST observations. You can check for those yourself by using the following command "show timezones"
I was able to find these but perhaps there are more and a specific one to CST/CLST. I tried searching for those but could not find anything:
NS-ISE-01/admin# show timezones | i Santiago
America/Santiago
NS-ISE-01/admin# show timezones | i Chile
Chile/EasterIsland
Chile/Continental
NS-ISE-01/admin# show timezones | i CLT
NS-ISE-01/admin# show timezones | i CLST
Let me know what you find. I would like to know the cause/resolution
Thank you for rating helpful posts!

Splitting front and back end servers across time zones

Weblogic Server 7.0
EJB is in Memphis,
jsp/servlets/web command classes are in Colorado
sending a date to the DB (in Memphis) results in a date getting changed by about 13 hours.
The change happens between the web command class in Colorado and the EJB command class in Memphis.
Any ideas as to what might be causing this and how to eliminate this bug would be very much appreciated.
Thanks.

Solution was that someone had configured the WLS to always operate dates in GMT, therefore the time differences between time zones were blown out of proportion...

ICal events are displayed in the local time zone, not at the time they are supposed to be

When I enter events in iCal (or in my iPhone calendar), they always display at the time for the zone that I am currently in, even when they occur in a different time zone. For example, if I have a lunch scheduled at 12 pm Monday in Vancouver, I want to see that I have something scheduled at 12 pm on Monday, even if I am in Hong Kong. But even if I have time zone support enabled, the event appears at 4 am Tuesday. This makes it hard to look at the calendar and know what events I have scheduled for what times when I am doing a lot of travel. Is there anyway that I can get the event to show up at 12 pm on Monday no matter where I am in the world?
Thanks

This means you're still using Flex 1.5 as your runtime. SAP has introduced Flex 2 RT on SP14 patch 1 onwards. There were a lot of bug fixes and also several new functionality introduced there. I suggest you consider upgrading to the latest SP. Note that you can upgrade VC apart from the portal (only 3 SCAs to deploy) so this means you don't impact the portal itself and continue to have an up-to-date version of VC.
If you want to solve your problem, I suggest you open a support ticket at SAP and once they see this, they'll let you have those SCAs.
Regards,
Natty

Time zones being re-written when files are processed from refernced files

I'm having a problem where photos with time zones set are being re-written automatically to whatever time zone my mac is currently set at when Aperture processes them for viewing regardless of the time zone they were set to. This happens as the photos load for viewing (i.e. not on the browser thumbnail view). It does this one at a time and eats up processing time. This seems to only happen (I think) for referenced files stored on my external drive and not those stored in the Aperture library. If I re-set the photos back to the proper time zones using Batch Change, it still happens next time it has to load the photo into memory, again "processing" and again the time zone reset to whatever time zone I'm now in.
Here's the exact situation:
- I've imported several photosets from a Canon 50D. The camera was set to the time zone of the country in question. Let's use India at GMT +5:30 as an example.
- When I import the photos, I also use the time zone presets, setting both the Camera Time and the Actual Time to GMT +5:30.
- I'm importing the photos as referenced files, storing them on an external hard drive.
- So when I first view the photos, the time and date show correct. Again using a real example IMG_0001 shows the date 6/10/10 1:43:31 PM GMT +05:30.
- Now I close Aperture and re-open.
- I open the folder and view the photo. The "loading" message appears at the time and the "processing" message appears on the bottom. (and during this unnecessary processing, it is very slow flipping to the next photo, a serious annoyance in browsing).
- After processing, the photo IMG_0001 now shows the date as 6/10/10 1:43:31 PM GMT +03:00 (the time zone I'm currently in and the one my Mac is currently set to)
- If I close it again and re-set my Mac to say I'm in London at GMT, and re-open, the photo is re-set instead to GMT.
- I can re-set all the dates to the proper time zone using the Batch Change where I again set both the Camera Time and Actual Time to the correct time zone. But when the photo re-loads, it again re-processes and goes back to the date of the Mac. So changes don't seem to stick.
- This appears to happen only to files that are referenced and stored on my external drive, not those stored in the Aperture library.
Has anyone had this problem? Is it a bug or some hidden setting I'm missing? Is there some way to tell Aperture "don't change the dates, ever, unless I do it via batch change"? The problem turns into a major inconvenience in reviewing and editing photos with it taking the extra processing time every photo and messing around the order.

maybe you try this question also in the dedicated Adobe Illustrator Forum, not many inhere (including me) have much experience with Illustrator nor live trace I'm afraid.

Wrong interpretation of OS time zone

This problem exists for Oracle 9.0.1.1.0 on Solaris 8.
The same Java method (using new Date() to get the current datetime) that shows correct datetime when called directly from Solaris console, produces wrong datetime when called as Oracle Java stored procedure.
This problem is visible for Middle/Central European Time zone which is GMT+1.
When timezone is set to MET in the OS, then the result of new Date() is datetime appropriate for GMT+03:30 not GMT+01:00.
When timezone is set to CET in the OS (which on Solaris is equivalent to MET), then the call to new Date() gives datetime appropriate for the GMT zone.
I can see that the timezone name used in Solaris is (wrongly) interpreted by the JVM as if it were set in Java, because in Java MET represents time zone in Iran! not in Middle/Central Europe. The call to TimeZone.getTimeZone("MET").getDisplayName() results in "Iran Time".
CET does not exist in Java (they use ECT instead) and is thus by default treated as GMT.
It is not reported in the list of bug fixes for Oracle 9i Release 2 so I assume the problem is still there.
Marek Rudnicki

Hello;
Fix the time on the OS and restart the database and you should be done. Simple as that. So to answer your question Right.
Best Regards
mseberg

Conversion mapping is losing time zone data during daylight saving time

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

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

Time Zone Bugs In 10.10.2

Similar Messages

Maybe you are looking for