Re: [android-developers] Re: Timezone Question
Ah. I'd guess, from what you're telling me, that the user's phone has the wrong time, the wrong local time zone, and the correct local time display. I'm not sure how we'd figure that out for sure Anyway, your idea of an override preference is probably the best thing you could do in your software (if it's worth it). But might it be better to tell the user that he can set the timezone to use in Google Calendar's web interface? Google Calendar stores actual times (rather than formatted times). If you set the time to use in the web interface, you can even set an event to start in one time zone and end in another! Of course, it's possible he's using some broken third-party software to access his Google Calendar -- but if he's using the standard app, or he uses the web interface correctly, it should work properly, and he shouldn't need to lie to his phone. On Sun, Apr 24, 2011 at 6:20 AM, Jake Colman wrote: > > Bob, et al, > > Wow! Great comments and replies. Thanks! > > The sunrise/sunset time is given in UTC based on lat/long. As another > poster said, I do have that part down pat. My only concern is with how > to display the time for the correct timezone. > > My user has manually set his timezone because of a problem with Google > calendar. He never wants the phone to know that it might have changed > timezones. The phone still displays the correct time for the local > timezone. His request is that since the phone knows the correct time, > why is my app not displaying the "correct" time for sunset. > > I think I will go with one of the other poster's comments. Since the > phone is being told its timezone, the app will do what its told. If it > becomes important, I can always add a preference to allow a user to > override the timezone setting for the app. > > Thanks for all the help! > > ...Jake > > > > "BK" == Bob Kerns writes: > > BK> While one hopes he does, it's not always a good assumption. But > BK> that aspect wasn't the intended focus of my remarks. > > BK> The point is -- the timezone SHOULD have absolutely ZERO impact > BK> on the actual calculated times. > > BK> There are really only three ways to get an error here that I can > BK> see. (Chime in if you can come up with more!) > > BK> * Using the wrong location. > BK> * Doing the wrong calculation. > BK> * Displaying with the wrong timezone (including DST errors, but that > BK> shouldn't be possible as a program error that I can see). > > BK> A fourth possibility is a confused user; I'm not sure how to > BK> break down the possibilities there -- though using a TZ with > BK> different DST characteristics might be included. > > BK> But I think the first step in sorting out the problem is to > BK> identify which problem you have, and that was why I was covering > BK> the territory. I hope the OP understands that I don't know any > BK> details of his knowledge or app, and can disregard any aspect of > BK> my message he's confident he's adequately eliminated! > > BK> On Sat, Apr 23, 2011 at 8:40 AM, String < > sterling.ud...@googlemail.com>wrote: > > >> No offense, Bob (and I do mean that, I value your posts on this > forum), but > >> I think we can safely assume that the OP knows how to calculate times > of > >> sunrise and sunset. He's already showing that in his app, from the > sound of > >> things, and is probably doing OK with that aspect. > >> > >> The issue at hand is how (and maybe whether) to work around a user > having > >> set their phone to a different zone than the one they're actually > >> in. Nobody > >> says this is affecting the absolute (UTC) time of sunrise/sunset in > the > >> calculations, it's purely about display. > >> > >> String > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Android Developers" group. > >> To post to this group, send email to > android-developers@googlegroups.com > >> To unsubscribe from this group, send email to > >> android-developers+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/android-developers?hl=en > >> > >BK> -- > BK> You received this message because you are subscribed to the Google > BK> Groups "Android Developers" group. > BK> To post to this group, send email to > android-developers@googlegroups.com > BK> To unsubscribe from this group, send email to > BK> android-developers+unsubscr...@googlegroups.com > BK> For more options, visit this group at > BK> http://groups.google.com/group/android-developers?hl=en > > -- > Jake Colman -- Android Tinkerer > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this
Re: [android-developers] Re: Timezone Question
While one hopes he does, it's not always a good assumption. But that aspect wasn't the intended focus of my remarks. The point is -- the timezone SHOULD have absolutely ZERO impact on the actual calculated times. There are really only three ways to get an error here that I can see. (Chime in if you can come up with more!) * Using the wrong location. * Doing the wrong calculation. * Displaying with the wrong timezone (including DST errors, but that shouldn't be possible as a program error that I can see). A fourth possibility is a confused user; I'm not sure how to break down the possibilities there -- though using a TZ with different DST characteristics might be included. But I think the first step in sorting out the problem is to identify which problem you have, and that was why I was covering the territory. I hope the OP understands that I don't know any details of his knowledge or app, and can disregard any aspect of my message he's confident he's adequately eliminated! On Sat, Apr 23, 2011 at 8:40 AM, String wrote: > No offense, Bob (and I do mean that, I value your posts on this forum), but > I think we can safely assume that the OP knows how to calculate times of > sunrise and sunset. He's already showing that in his app, from the sound of > things, and is probably doing OK with that aspect. > > The issue at hand is how (and maybe whether) to work around a user having > set their phone to a different zone than the one they're actually in. Nobody > says this is affecting the absolute (UTC) time of sunrise/sunset in the > calculations, it's purely about display. > > String > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
RE: [android-developers] Re: Timezone Question
Forgot to mention. I'm not sure if you are already using this but the Navy has a nice pearl script you can POST to and retrieve a good bit of Sun/Moon data. They have to forms one allows you to enter the city name and state to get the data (not all cities are listed) the other allows you to specify lat/lon and a few other fields to get that sun/moon data for anyplace in the world. The forms are below: For City Name/State only: http://www.usno.navy.mil/USNO/astronomical-applications/data-services/rs-one -day-us For the more advanced form: http://www.usno.navy.mil/USNO/astronomical-applications/data-services/rs-one -day-world Let me know if you have any issues using these forms. I'll be more than happy to assist From: android-developers@googlegroups.com [mailto:android-developers@googlegroups.com] On Behalf Of String Sent: Saturday, April 23, 2011 11:41 AM To: android-developers@googlegroups.com Subject: [android-developers] Re: Timezone Question No offense, Bob (and I do mean that, I value your posts on this forum), but I think we can safely assume that the OP knows how to calculate times of sunrise and sunset. He's already showing that in his app, from the sound of things, and is probably doing OK with that aspect. The issue at hand is how (and maybe whether) to work around a user having set their phone to a different zone than the one they're actually in. Nobody says this is affecting the absolute (UTC) time of sunrise/sunset in the calculations, it's purely about display. String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
RE: [android-developers] Re: Timezone Question
Jake, I have a vb project that auto detects Time Zone and Day Light Savings Time.. I found these JS files online and they seem to work great.. TimeZoneDetection.js : //Provided by http://www.michaelapproved.com/articles/timezone-detect-and-ignore-daylight- saving-time-dst/ function TimezoneDetect() { var dtDate = new Date('1/1/' + (new Date()).getUTCFullYear()); var intOffset = 1; //set initial offset high so it is adjusted on the first attempt var intMonth; var intHoursUtc; var intHours; var intDaysMultiplyBy; //go through each month to find the lowest offset to account for DST for (intMonth = 0; intMonth < 12; intMonth++) { //go to the next month dtDate.setUTCMonth(dtDate.getUTCMonth() + 1); //To ignore daylight saving time look for the lowest offset. //Since, during DST, the clock moves forward, it'll be a bigger number. if (intOffset > (dtDate.getTimezoneOffset() * (-1))) { intOffset = (dtDate.getTimezoneOffset() * (-1)); } } return intOffset; } DSTDetection.js: // provided by http://www.michaelapproved.com/articles/daylight-saving-time-dst-detect/ //Find start and end of DST function DstDetect() { var dtDstDetect = new Date(); var dtDstStart = ''; var dtDstEnd = ''; var dtDstStartHold = ''; //Temp date hold var intYearDayCount = 732; //366 (include leap year) * 2 (for two years) var intHourOfYear = 1; var intDayOfYear; var intOffset = TimezoneDetect(); //Custom function. Make sure you include it. //Start from a year ago to make sure we include any previously starting DST dtDstDetect = new Date() dtDstDetect.setUTCFullYear(dtDstDetect.getUTCFullYear() - 1); dtDstDetect.setUTCHours(0, 0, 0, 0); //Going hour by hour through the year will detect DST with shorter code but that could result in 8760 //FOR loops and several seconds of script execution time. Longer code narrows this down a little. //Go one day at a time and find out approx time of DST and if there even is DST on this computer. //Also need to make sure we catch the most current start and end cycle. for (intDayOfYear = 1; intDayOfYear <= intYearDayCount; intDayOfYear++) { dtDstDetect.setUTCDate(dtDstDetect.getUTCDate() + 1); if ((dtDstDetect.getTimezoneOffset() * (-1)) != intOffset && dtDstStartHold == '') { dtDstStartHold = new Date(dtDstDetect); } if ((dtDstDetect.getTimezoneOffset() * (-1)) == intOffset && dtDstStartHold != '') { dtDstStart = new Date(dtDstStartHold); dtDstEnd = new Date(dtDstDetect); dtDstStartHold = ''; //DST is being used in this timezone. Narrow the time down to the exact hour the change happens //Remove 48 hours (a few extra to be on safe side) from the start/end date and find the exact change point //Go hour by hour until a change in the timezone offset is detected. dtDstStart.setUTCHours(dtDstStart.getUTCHours() - 48); dtDstEnd.setUTCHours(dtDstEnd.getUTCHours() - 48); //First find when DST starts for (intHourOfYear = 1; intHourOfYear <= 48; intHourOfYear++) { dtDstStart.setUTCHours(dtDstStart.getUTCHours() + 1); //If we found it then exit the loop. dtDstStart will have the correct value left in it. if ((dtDstStart.getTimezoneOffset() * (-1)) != intOffset) { break; } } //Now find out when DST ends for (intHourOfYear = 1; intHourOfYear <= 48; intHourOfYear++) { dtDstEnd.setUTCHours(dtDstEnd.getUTCHours() + 1); //If we found it then exit the loop. dtDstEnd will have the correct value left in it. if ((dtDstEnd.getTimezoneOffset() * (-1)) != (intOffset + 60)) { break; } } //Check if DST is currently on for this time frame. If it is then return these values. //If not then keep going. The function will either return the last values collected //or another value that is currently in effect if ((new Date()).getTime() >= dtDstStart.getTime() && (new Date()).getTime() <= dtDstEnd.getTime()) { return new Array(dtDstStart, dtDstEnd); } } } return new Array(dtDstStart, dtDstEnd); } Hopefully this will help your situation ? From: android-developers@googlegroups.com [mailto:android-developers@googlegroups.com] On Behalf Of String Sent: Saturday, April 23, 2011 11:41 AM To: android-developers@googlegroups.com Subject: [android-developers] Re: Timezone Question No offense, Bob (and I do mean that, I value your posts on