There has been a longtime bug in the kweather, part of kdetoys, where locations that lies +/- 7 hours or more away will get either the wrong sunrise or sunset time. At the same time the icon has been selected wrongly too. Reproducible: Always Steps to Reproduce: 1. emerge kdetoys Actual Results: When locations that lies +/- 7 hours or more away is selected either the wrong sunrise or sunset time will be shown. At the same time the icon has been selected wrongly too, where you mostly have the night icon even if it's day time at the remote location. Expected Results: Show correct time for sunrise/sunset and the right weather icon based on it. Martin Koller and J.O. Aho has made patches that addresses thise faults and the patches has been adopted into the 3.8 series of kdetoys. M +18 -1 metar_parser.cpp M +26 -4 sun.cpp --- branches/KDE/3.5/kdetoys/kweather/metar_parser.cpp #616455:616456 at at -411,6 +411,8 at at { #define E(t) ::pow(10, 7.5*t/(237.7+t)) float fRelHumidity = E(weatherInfo.dewC)/E(weatherInfo.tempC) * 100; + if (fRelHumidity > 100.0) fRelHumidity = 100.0; + weatherInfo.qsRelHumidity.sprintf("%.1f", fRelHumidity); removeTrailingDotZero(weatherInfo.qsRelHumidity); weatherInfo.qsRelHumidity += "%"; at at -841,7 +843,22 at at longitude << " " << civilStart << " " << civilEnd << " " << m_localUTCOffset << endl; - return (currently < civilStart || currently > civilEnd); + if (civilStart != civilEnd) + { + if (civilEnd < civilStart) + /* Handle daylight past midnight in local time */ + /* for weather stations located at other timezones */ + return (currently < civilStart && currently > civilEnd); + else + return (currently < civilStart || currently > civilEnd); + } + else + { + // Midnight Sun & Polar Night - In summer, the Sun is always + // over the horizon line ... so use latitude & today date to + // set isNight() value. + return ((m_date.daysInYear() >= 80 || m_date.daysInYear() <= 264) && latitude.contains("S")); + } } } --- branches/KDE/3.5/kdetoys/kweather/sun.cpp #616455:616456 at at -204,20 +204,42 at at QTime result; // Example: say time is 17.7543 Then hours = 17 and minutes = 0.7543 * 60 = 45.258 + // We need to convert the time to CORRECT local hours int hours = (int)floor(time); + int localhours = hours + (m_localUTCOffset / 60); + + // We need to convert the time to CORRECT local minutes int minutes = (int)floor((time - hours) * 60); + int localminutes = minutes + (m_localUTCOffset % 60); - int localhours = hours + (m_localUTCOffset / 60); - if (localhours < 0) { localhours += 24; } - if (localhours >= 24) { localhours -= 24; } + // We now have to adjust the time to be within the 60m boundary + if (localminutes < 0) + { + //As minutes is less than 0, we need to + //reduce a hour and add 60m to minutes. + localminutes += 60; + localhours--; + } + if (localminutes >= 60) + { + //As minutes are more than 60, we need to + //add one more hour and reduce the minutes to + //a value between 0 and 59. + localminutes -= 60; + localhours++; + } // Round up or down to nearest second. // Use rint instead of nearbyint because rint is in FreeBSD int seconds = (int)rint( fabs( minutes - ((time - hours) * 60) ) * 60 ); + // We now have to adjust the time to be within the 24h boundary + if (localhours < 0) { localhours += 24; } + if (localhours >= 24) { localhours -= 24; } + // Try to set the hours, minutes and seconds for the local time. // If this doesn't work, then we will return the invalid time. - result.setHMS( localhours, minutes + (m_localUTCOffset % 60), seconds ); + result.setHMS( localhours, localminutes, seconds ); return result; }
This has been fixed in the 3.5 branch, months ago, therefore part of KDE 3.5.6.
