E61 timezone bug!!!

Hi, there seems to definitely be a bug in the E61 firmware 3.0633.09.04 in regard to the timezone for USA->Phoenix.
How do I report this or find out if there is a patch?
Basically, United States/Phoenix has GMT-0 rather than GMT-7. Previous firmwares did not have this problem.
Help!!!!!!
Dennis

It's very hard to find it... http://europe.nokia.com/A4164022?url=http://nds1.nokia.com/phones/files/software/Nokia_E61_WorldClockUpdate.SIS
Cheers

Similar Messages

ColdFusion Timezone Bug?

I'm working with values of time in seconds and I've come across an odd bug and I'm hoping someone might explain if this is a bug or if this is some kind of timezone issue. I have code which calculates the difference, in seconds, between two fixed dates. ColdFusion gives me one answer, native Java methods give me a different answer. The difference is one hour which makes me think this is somehow related to timezone, but I can't figure out how to properly correct for this.
Any insight would be greatly appreciated.
Here's my sample code:
<cfset variables.TimeZone = CreateObject( "java", "java.util.TimeZone" ) />
<cfset variables.Calendar = CreateObject( "java", "java.util.Calendar" ).getInstance( variables.TimeZone.getTimeZone( "GMT" )) />
<cfset variables.Calendar.set( 2010, 6, 20, 15, 40, 0 ) />
<h1>Seconds from 01/01/1970 12:00 AM to 07/20/2010 3:40 PM</h1>
<p>
    According to Java:
    <cfoutput>#Int( variables.Calendar.getTimeInMillis() / 1000 )#</cfoutput>
</p>
<p>
    According to ColdFusion:
    <cfoutput>#DateDiff( "s", "01/01/1970 12:00 AM", "07/20/2010 3:40 PM" )#</cfoutput>
</p>

what tz is the cf server in? not
UTC i take it? on the server i'm working on today the tz is ITC (no DST)
& i get:
According
to Java: 1279640400
According to ColdFusion: 1279640400
using your
snippet.
maybe
this http://bit.ly/a9ZXss
will have some insight for you.
So if ColdFusion treats dates and times as in the local timezone, and my local timezone has DST, then I need to check and correct for that. And there's no simple (by "simple", I mean a native ColdFusion function that can handle this difference) solution?
So I need to employ something like this:
<cfset variables.timeDiff = DateDiff( "s", "01/01/1970 12:00 AM", "07/20/2010 3:40 PM" ) />
<cfif GetTimeZoneInfo().isDSTon IS TRUE>
    <cfset variables.timeDiff = variables.timeDiff + 3600 />
</cfif>
<p>
    According to ColdFusion (Adjusted):
    <cfoutput>#variables.timeDiff#</cfoutput>
</p>
Which works. I just with there was something native to CF that could handle dates outside of local timezone rules.

J2sdk 1.4 Timezone bug?

Set timezone to be GMT and run this piece of code in j2sdk1.4,
     System.out.println(
       "ZONE_OFFSET 1: " + ((new GregorianCalendar()).get(Calendar.ZONE_OFFSET))
     System.out.println(
       "ZONE_OFFSET 2: " +
       ((new GregorianCalendar(1970, 0, 1)).get(Calendar.ZONE_OFFSET))
     System.out.println(
       "ZONE_OFFSET 3: " +
       ((new GregorianCalendar(1971, 9, 30)).get(Calendar.ZONE_OFFSET))
     System.out.println(
       "ZONE_OFFSET 4: " +
       ((new GregorianCalendar(1971, 10, 1)).get(Calendar.ZONE_OFFSET))
     System.out.println(
       "ZONE_OFFSET 5: " +
       ((new GregorianCalendar(1972, 0, 1)).get(Calendar.ZONE_OFFSET))
     );It will print:
ZONE_OFFSET 1: 0
ZONE_OFFSET 2: 3600000
ZONE_OFFSET 3: 3600000
ZONE_OFFSET 4: 0
ZONE_OFFSET 5: 0while in jdk1.3, it prints correct answers:
ZONE_OFFSET 1: 0
ZONE_OFFSET 2: 0
ZONE_OFFSET 3: 0
ZONE_OFFSET 4: 0
ZONE_OFFSET 5: 0Another strange thing is that in other timezone such as US EST, j2sdk1.4 will print the correct numbers after running the above code:
ZONE_OFFSET 1: -18000000
ZONE_OFFSET 2: -18000000
ZONE_OFFSET 3: -18000000
ZONE_OFFSET 4: -18000000
ZONE_OFFSET 5: -18000000It seems to be a bug in j2sdk1.4.
Help is appreciated.

There is no "default offset" for a Calendar. The
zone offset depends on the default time zone. The default zone in turn depends
on the host zone. There is no reason to expect the value of
Calendar.get(ZONE_OFFSET) to necessarily remain constant between releases or
even between machines in the same release or between runs on the same machine.

Outlook Calendar Timezone bug

I am having an issue with displaying the time on the calendar after the daylight saving apply to the Pacific Timezone.
I have Outlook Version 14.0.7113.5005 (32-bit) installed on the Window 7 32 bit machine.
I tried the Time Zone Daylight Saving Update Tool that Microsoft provided, but it doesn't seem like it works for me.
Anyone have an idea on how to solve this issue?
Thanks.

Hi,
First please make sure your Windows and Office are both fully patched.
I also suggest you confirm that the time zone settings for your computer's system clock and your Outlook Calendar are the same.
Regards,
Melon Chen
TechNet Community Support

E61 - annoying bug regarding ringtone-associations

Hi,
I have an E61 and I hope somebody can give me any advice on this: There is the possibility of assigning an individual ringtone to any contact. There is also the possibility of setting up different profiles, each with a specific ringtone and a specific message tone.
The trouble is, any ringtone that has been individually assigned to a contact seems to override the settings made in the profiles - so whenever that contact calls, there is a different ringtone than the one set up in the profile. That might have its advantages all right, but I just don´t want it - but I can´t seem to find any way to get rid of it again: Once I have assigned a ringtone to a contact, there is no option to remove it - all I can do is select another one which would merely alter the issue, not solve it.
I haven´t yet tried if individually assigned ringtones override special profiles like "Meeting" - that would be most annoying - but it is annoying enough as it is.
Can anybody tell me how to get rid of an assigned ringtone without selecting any other one so that when that contact calls, the phone will just fall back on the ringtone set up in the profile?
Thank you very much!
Regards,
Hendikoischnur
IT will paint our future - either green or black
* ecosia, the eco-friendly search engine (powered by Yahoo/Bing/WWF);
* Searching for pics online? Try ecocho.eu or treehoo.com
* For those who don´t want to miss Google: Try znout.de - it´s Google running on green energy
* CO2-free chatting: Try Jabber-server.de (running on 100% waterpower)
Solved!
Go to Solution.

Hi no1_slumko,
why does it "defeat the purpose of..." when, after assigning a special ringtone to any one contact, I want to be able to remove that "tag" again and have the contact without any other ringtone than the one set up in my profile?
The problem is, that option reacts very proactively - as soon as I merely look into the option of assigning a special ringtone to a contact, I guess, one does get assigned this contact and the ringtone set up in the profile is overridden. What´s missing is a possibility of clearing the contact of this specially assigned ringtone again.
Regards,
Hendikoischnur
IT will paint our future - either green or black
* ecosia, the eco-friendly search engine (powered by Yahoo/Bing/WWF);
* Searching for pics online? Try ecocho.eu or treehoo.com
* For those who don´t want to miss Google: Try znout.de - it´s Google running on green energy
* CO2-free chatting: Try Jabber-server.de (running on 100% waterpower)

Iphone Time/Timezone bug.

I have an Iphone that is having some odd time bug. It appears to wind up 15-20 minutes behind, and when I toggle "Set Automatically" in Date & Time it will go five or so hours behind then correct itself to the proper time, then eventually wind up minutes behind again. The person is hesitant to restore their phone because they will lose some content. Any idea what could be causing the issue? The phone is a Iphone 5c with Ios 7.1.1.

Is iPhone hacked?
The time is sync with the cell tower, try a
Reset: Hold down the Sleep/Wake button and the Home button at the same time for at least ten seconds, until the Apple logo appears. Note: You will not lose any data
If no joy that person should do
Restore from backup
or
Restore as new
http://support.apple.com/kb/HT1414

E61 Spreadsheet bug

The spreadsheet has a major flaw with cells formatted as percentage. Formating a cell as percentage changes its value!
eg with the value 0.5 in cell A1, and a formula =A1*100 in cell B1, the result is 50 as you'd expect. Now format A1 as % and the result changes to 0.5 ! And the formated cell shows the incorrect value 0.5% instead of 50%.
Any .xls sheets that use cells formatted as % give the wrong answers
Also, how do I copy/paste cells?
When creating a formula, is there any way to pan around the spreadsheet & select the cell or range I want to use in the calculation?Message Edited by gooseye on 04-Jul-2006
10:46 AM

It's very hard to find it... http://europe.nokia.com/A4164022?url=http://nds1.nokia.com/phones/files/software/Nokia_E61_WorldClockUpdate.SIS
Cheers

Request fix for timezone related bugs

To Adobe Lightroom employees...
Even the new release of LR3 still has age old timezone bugs which are likely infuriating for anyone who shoots in more than a single timezone.
Problem 1: LR ignores camera metadata relating to timezone.
Solution 1: Include a time/date panel in the importer dialog. If camera metadata is present, use it to set defaults. Provide options for shifting both the time and the timezone (e.g. can shift 2010-01-01T01:05:06+01:00 to become 2010-01-01T01:02:03-02:00). This info can be stored in LR database and in exported XMP data.
Problem 2: LR exports incorrect timezone data.
Solution 2: Due to EXIF limitations this cannot be guaranteed correct. Provide an option to export EXIF date/time using a specified timezone (origination/computer/other).
Other problems: File renaming issues relating to timezones, sorting in grid view, etc.
Solutions: If every file has an assigned timezone, all these should become moot points, as information is held to get it right.
The bottom line is that most timezone issue have been present since Lightroom was initially released, and numerous people are frustrated with having purchased a leading product with a glaring set of bugs which corrupt valuable metadata, and interrupt workflow. Providing fixes for these bugs and facilities for handling them sensibly and gracefully, along with default options to provide the current behaviors, allows for the best of both worlds. Date/time are key bits of metadata for any photo, and an inability to handle this properly in one of the leading brands of software is, quite frankly, inexcusable. New features keep being included, yet important basic functionality such as this gets left aside; please prioritize this for the next release to appease many long-suffering, paying customers.
Stan

I too wish that Lightroom would handle date/times with time zones and let users manipulate them. LR 3 consistently ignores time zones; see this post for details:
http://forums.adobe.com/message/2931846#2931846
I think the root cause of this mess is that the EXIF standard, defined in 1998, doesn't support time zones (hard to believe that a standards committee would make such a basic mistake). Even though Adobe's XMP standard requires the use of time zones, LR ignores them!

Mysql on macbook

hello, i have a macbook running mac os x, version 10.6.1. I have apached setup and
am running php as well. I recently downloaded and installed mysql and mysql gui tools.
I tried to connect to mysql via mysql administrator and got the following error:
connection error
could not connect to mysql instance at localhost
error can't connect to local mysql server through socket 'tmp/mysql.sock'(2) (code2002)
I'm a developer and have picked up a mac to begin coding on the mac. I have a VAMP running and
it works great; just want to figure out how to get mysql running on the mac.
thanks

HI,
Im having a similar problem.
However, here are some things I've discovered. If you go to the directory that you're pointing at, there's nothing there.
If you've downloaded and installed the 5.1.x version from MySQL site, then you're probably having the same problem I'm having....PHP sees the 5.0.51 version but not the correct version that you've installed.
Are you running the proper 64bit version or 32 ? It makes a difference. Im running 64 and I can't get PHP to connect.
Further the MySQL admin is a piece of crap! Always has been on the mac. Get Navicat. You'll be happier. You can at least connect to your databases. PHP is a whole other story.
Still another little detail is the date.timezone bug that's now present. Find this line in your PHP.INI file:
;date.timezone =
and uncomment it. Then add your time zone location. http://php.net/manual/en/timezones.php
Hope that helps....
Miles

LiveView on Droid X, Text Messaging Doesnt Display

Hi All,
I got a LiveView last week and so far on my DroidX everything seems to work about as well as I expected, EXCEPT Text Messaging never displays on the LiveView.
This was a major feature I hoped would work even if some of the other less important ones didnt.
Does anyone have any ideas as to how to get Text Messages to display on a DroidX?
Ive tried everything I can think of but nothing seems to make any difference.
I really like the concept of the LiveView and would like to see it develop rapidly.
Thank you.

ISSUE RESOLVED!!
EXPLANATION OF ISSUE (FOR SONYERICSSON TECHNICIANS TO FIX IT THE RIGHT WAY)
The problem you are having is a common one for Droids on Verizon's CDMA network, as well as Rogers in Canada and Sprint PCS. Its just another form of the SMS time offset issue that's been plaguing us all for years...
for some stupid reason, the CDMA network timestamps all messages in GMT, rather than the local timezone
This issue is annoying, and should have been fixed in the verizon distributions of android a long time ago, but it is compounded by a confusing programming choice made by Sony Ericsson:
Inside the dex file of the apk, in "com/sonyericsson/exttras.liveview/LiveViewService$9.class" on line 31 (ignoring blank lines and comments), there is a test run on the timestamp... (the exact code is "if (l1 > l2)")... THIS TEST FAILS ON ALL CDMA PHONES WITH THE TIMEZONE BUG
I'm not sure why they were working it that way, but they should have simply tested to see if the message was newer than the last message received... they apparently did not.
HOW TO MAKE IT WORK (WITHOUT MODIFYING THE APK FILE)
install SMS Time Fix from the market, and set the offset method to "timezone". This fixes the issue, as well as issues with message order in restored backups.

Bug In Java 5 Date/Calendar Timezone Implementation (possibly 6 also)

Hey All,
Really been scratching my head over a date issue I've observed for a while now in relation to TimeZone handling in java.
It first manifested itself as strange behaviour in my Default TimeZone "Europe/Dublin" (ie. GMT with DST)
e.g:
System.setProperty("user.timezone", "Europe/Dublin");
Date epoch=new Date(0);
System.out.println("Epoch:"+epoch);
yields:
Epoch:Thu Jan 01 01:00:00 GMT 1970
1AM (BUG???????)
If I set the TZone above to GMT it outputs correctly as
Epoch:Thu Jan 01 00:00:00 GMT 1970
As there is no offset from GMT I can only think that DST is being handled incorrectly around the epoch. (even though it is not in DST on Jan 1st)
So I wrote the following test using calendars to test my theory.
          System.setProperty("user.timezone", "UTC");
          Calendar test=Calendar.getInstance(); //will use the user.timezone
          Calendar test2=Calendar.getInstance(TimeZone.getTimeZone("Europe/Dublin"));
          for (int year=1965;(year<=1975);year++){
               test.clear();test2.clear();
               test.set(year, 0, 1, 0, 0, 0);
               test2.set(year, 0, 1, 0, 0, 0);
               System.out.println("UTC:"+ test.getTime()+ " --- EU/Dub:"+test2.getTime());
Which yields the following interestingly inconsistent output (BUG?????)
UTC:Fri Jan 01 00:00:00 UTC 1965 --- EU/Dub:Fri Jan 01 00:00:00 UTC 1965
UTC:Sat Jan 01 00:00:00 UTC 1966 --- EU/Dub:Sat Jan 01 00:00:00 UTC 1966
UTC:Sun Jan 01 00:00:00 UTC 1967 --- EU/Dub:Sun Jan 01 00:00:00 UTC 1967
UTC:Mon Jan 01 00:00:00 UTC 1968 --- EU/Dub:Mon Jan 01 00:00:00 UTC 1968
UTC:Wed Jan 01 00:00:00 UTC 1969 --- EU/Dub:Tue Dec 31 23:00:00 UTC 1968
UTC:Thu Jan 01 00:00:00 UTC 1970 --- EU/Dub:Wed Dec 31 23:00:00 UTC 1969
UTC:Fri Jan 01 00:00:00 UTC 1971 --- EU/Dub:Thu Dec 31 23:00:00 UTC 1970
UTC:Sat Jan 01 00:00:00 UTC 1972 --- EU/Dub:Sat Jan 01 00:00:00 UTC 1972
UTC:Mon Jan 01 00:00:00 UTC 1973 --- EU/Dub:Mon Jan 01 00:00:00 UTC 1973
UTC:Tue Jan 01 00:00:00 UTC 1974 --- EU/Dub:Tue Jan 01 00:00:00 UTC 1974
UTC:Wed Jan 01 00:00:00 UTC 1975 --- EU/Dub:Wed Jan 01 00:00:00 UTC 1975
Strange - ehh? 1969->1971 all have issues with the Jan 1st date!!!!
In fact theres issues for every day that DST is not in operation on these years... (BUG????)
I'm part of a project that will be handling data from all Timezones and as such we have chosen
to use UTC as our server time. We are now quite concerned what other bugs/strange behaviours
lurk beneath the surface of the java implementation.
Note we have tested various JDK's and they seem to be consistently inconsistent!
If anyone can confrim this bug/issue or shed any light it would be most appreciated,
G.

miniman wrote:
As there is no offset from GMT I can only think that DST is being handled incorrectly around the epoch. (even though it is not in DST on Jan 1st)Well, in the UK, DST was in effect on 1970 Jan 01. I wouldn't be surprised to find that the same applied in Ireland.

Aperture ... Bug .... timezones and smart albums

Hello everyone,
i've just jumped into the mac world a week ago, just bought my first macbook ! Yeah !
I decided to give Aperture a try, and given i've played with it now for 2 days, if this bug I found is really there, NO WAY am I going to pay for such software !
I've been using Picasa on PC for the past couple years now.
Its handling my photo library extremely well: over 50gb of photos, 10 years worth of photos.
So after looking at all the Aperture videos on the apple site, I decided to give it a try to replace my picasa, since there is no picasa for my new mac.
The bug I found (and I'm a newbie !, 2 days of playing, struggling to import my pictures, and bam ... bug .... hummmm).
I tried importing only 1 folder in my library.
I'm french and this summer, went to USA for holiday. Western deserts and all.
So, I took my folder:
2008 08 09 - USA Grand West
And tried importing it.
It contains around 100 photos of the 1st 3 days of the trip.
My camera was set to French time, so at import I appreciated the "Change time thingy" and set it to Los Angeles time.
Did the import in a new project.
Great.
All pictures in the project. Exif Date updated to los angeles time. GREAT !
Now.
I want to have them show up on a day to day basis.
So, I created smart albums giving the date I wanted.
August 9 2008, August 10 2008 and August 11 2008.
It DOES NOT WORK ! BUGGGGGGGG
photos taken on the 3rd day, having correct EXIF date metadata, show 11/08/2008 for the date (correct), however they are not shown in the August 11 2008 album !
They are shown in the August 12 2008 album !
Reason !
The smart album is using the wrond date. The French one.
Since there is 11 hours difference.
Some late August 11 (Los Angeles time) pictures are pushed to August 12 (early morning French time).
Am I the only one with this bug ?
The only fix I found for now that works, is adding 3 rules to the smart albums:
- exif: day of the month = 11
- exif: month of the yar = 08
- exif: year = 2008
That works.
However there is NO WAY, i'm setting up 50gb worth of smart albums having to apply 3 specific rules to compensate for a bugged out calendar rule that does not work.
Any ideas ? fixes ?
Thanks
Regards
Tim

Hum, i'm not sure I understand what is going on, or what you are describing.
you say: "... Aperture is correct in it's assertion the image was taken on 12th"
I dont understand.
When i've done the import, and look at that pictures metadata, the date/time is corrected. It shows up as 15:42 20080811 (youre writting).
So if the metadata is correct, I really dont understand how the computers time and timezone has any effect on the smart albums ... could you explain ?
Unless what you are suggesting, is that the smart album date is applied to the computers time zone, and thus when searching for the files, it automatically does a conversion of the time of the picture to fit the computers timezone => thus my 15:42 20080811 set to Los Angeles time zone, is researched using a French timezone and thus found on 00:42 20080812 ?
Wow, if so, this would be a stretch !
And if this is the answer, I do not understand the "feature" to import using a different time zone, and not be able to search according to it ?
There is effectively no point?
In respect to the workaround you describe. Its effectively what I did, I sorted using 3 criterias: exif day of the month = 11, month of the year = 08, year = 2008. And for some reason that works !
Would there be another workaround? Instead of using the TimeZone panel, import them untouched, and doing a batch Time change on the pictures once imported and leaving them at the same Paris timezone, but compensating for 9 hours, effectively, bringing them to 15:42 Paris time, instead of Los Angeles time ?
If my memory is correct when having played with this, the batch time modification, did not compensate the days: Effectively, clicking 9 times on the down arrow when showing 00:42 12th did not change the 12th into an 11th ...

Bug report - OOB site column ArticleStartDate is crawled according to GMT0 not user/server timezone

This issue can be reproduced easily on any SP2013 farm (on-premise) and I heard Sharepoint online do not have this problem.
Issue: Site column "Article Date" with fieldname "ArticleStartDate" is crawled as GMT 0 regardless what timezone your web application, site setting, user setting and OS are set. Also when you submit a search you need to use GMT 0
otherwise you will get wrong result. I believe it is bug because other datetime columns like "Modified" have handled timezone issue very well.
To reproduce: On a SP2013 farm (on-premise), check your timezone settings (in my environment it is GMT+8). Then create a site collection and enable its Publishing Infrastructure feature. Then you will see some site columns are setup including "Article
Date" (field name "ArticleStartDate"). Now create a custom content type and add some columns including "Article Date" to it. Create some sample items using the custom content type and remember fill in the value for "Article Date".
By default it should allow you pick a "Date" only. After save the change you should see "Article Date" is saved like "2014-06-18 00:00:00" if check with powershell.
After create some sample items start a full crawl. You will see find two crawled property "ows_q_DATE_ArticleStartDate" and "ows_ArticleStartDate" appear in Search Service Application -> Search Schema. There are some existing managed
properties mapping to those crawled properties like "ArticleStartDateOWSDATE" (which is TEXT datatype).
Here you can create some new managed property or use existing. Apply search using those properties to test. In my lab, I created "NewsArticleDate" as managed property and mapping to ows_ArticleStartDate. Then I create a blank
page and add a "Search result" and "refinement panel" webpart and start some search. In the refinement panel added in the managed properties setup in previous steps. In the querystring I typed in something like /search.aspx?k=newsarticledate=YYYY/MM/dd
It is what I see:
1. As you can see in the refinement panel, because I am at GMT+8 and crawled index at GMT 0, the sample data "2014-06-18 00:00:00" will become "2014-06-17 16:00:00".
2. Hence, in order to search out "2014-06-18 00:00:00" item I have to input "2014-06-17" in search query! (in SP2013 the time part are ignored)
3. By using the powershell provided by Ivan Josipovic (http://gallery.technet.microsoft.com/office/Get-Crawled-Property-names-9e8fc5e0), I can see the items
ows_ArticleStartDate is "2014-06-18 00:00:00".
I hope it is actually not a bug. Please let me know if my setting is wrong. Thank you!

Hi Mark,
According to your description, my understanding is that the Article Date column displayed with the value based on GMT0 in the Refinement web part.
Microsoft SharePoint stores date and time values in Coordinated Universal Time (UTC, but also named GMT or Zulu) format, and almost all date and time values that are returned by members of the object model are in UTC format. So the value
of the Article Date column stores the date and time in UTC format in the database, and the search indexes the UTC value of the Article Date column after crawling the database so that it displays the UTC value in Refinement web part.
The list column values displayed in the lists that are obtained through the indexer for the SPListItem class are already formatted in the local time for the site so if you’re working on current context list item and fetch a datetime field
like so SPContext.Current.ListItem["Your-DateTime-Field"] you’ll retrieve a DateTime object according the specified time zone in the regional settings.
More references:
http://francoisverbeeck.wordpress.com/2012/05/24/sharepoint-tip-of-the-day-be-careful-when-wor/
Thanks,
Victoria
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Victoria Xia
TechNet Community Support

Timezone and Birthday bug in Address Book

Hello,
I just found a bug related to the Address Book, birthday fields, and timezones in 10.4.6. I had many contacts with filled birthdays. I had my system timezone set to Brazil (GMT-3), but now I moved to Japan, and set the timezone to Japan (GMT+9). When I opened Address Book after that, all birthday fields are showing one day late (for instance, if the birthday was on 1978/02/24, it will now show as 1978/02/25). Consequently, the birthdays in iCal are also showing late.
I guess this is an internal representation bug, in that the birthdays are stored with the timezone, and when I changed the system timezone the correct date started being recalculated. But as a "timeless" event, birthdays should only display at the set date, without any conversion.
PowerBook G4 12 Rev. A/iPod with Video 30GB Mac OS X (10.4.3)

You seem to be right. Here is what I noticed with further experimentation.
The time difference between Brazil and Japan is 12 hours, that is, in any given day, when it reaches noon (12:00) in Japan, the day is just starting (00:00) in Brazil, and when it reaches noon (12:00) in Brazil, that same day is ending in Japan (23:59). So, during the period 12:00-23:59 in Japan (and 00:00-11:59 in Brazil), both places are under the same day.
Here is the interesting bit: birthday events added in Brazil during this period (before noon) show with the correct date, when I set the timezone do Japan. Birthday events added in Japan in the afternoon also show the correct date when I set the timezone back to Brazil's. So Address Book is using the field edit date, somehow.
For now, I have manually reedited all the birthday fields during this "same day" period, and birthdays are showing correctly no matter if I am in Brazil or Japan, but that is definitely a hack.

E61 SIP realm bug !

Hello,
[My E61 use the latest firmware from july 2006]
There is an important bug with the E61 SIP.
Its impossible to create 2 differents accounts with the same realm (domain) name !?!?
Exemple, i have two accounts with realm *freephonie.net*, but E61 dont accept the second account.
Perhaps, one day..., this #!:#=# !!! bug will be removed.
But i must to find a solution, now.
So i would be glad to know the name of the file where i can found and modify "by hand" these parameters in th E61.
Manny thanks in advance.
(Sorry for my so bad English)
Jean Louis
PS : I have read, here, that other peoples have same problem without any answer from Nokia (Is it Nokia forum here ???)
So if its not the good place for this problem, where to go ?
Message Edited by silver84000 on 22-Nov-2006
02:32 PM
Message Edited by silver84000 on 22-Nov-2006
02:33 PM

This is a user to user assistance forum, the Nokia staff only act as moderators rather than give advice or fixes.
I have full End User experience of:
5510, 3210, 3310, 3510, 3510i, N80, N80IE, 7610, 2610, 1208 and current E90.

E61 timezone bug!!!

Similar Messages

Maybe you are looking for