Closed kfix closed 9 years ago
Hi @kfix. Co-incidentally, I noted that same error yesterday, while making some other fixes and improvements to that evidence source, after one of previous reports sent to @dustinrue and me. And I have just pushed a fix for the over-midnight logic to the main branch today. If you can get the updated sources on your system, compile and test, it should work well now. (Let us know how it goes for you.)
Vladimir
yep, master works right on my mac with a cross-midnight rule, and it doesn't mess with normalizing all the NSDates. thanks
Hi all, I have revised and throughly tested some changes to my previously-applied patch for cross-midnight TimeOfDay rules. I found that such rules (nighttime context == "7PM - 7AM") did not always work on my system and I had to keep splitting them into two halves (7PM - 11:59PM, 12AM - 7 AM).
I wish I could make it cleaner, but we cannot use newer methods from OSX 10.9 like NSDate.startOfDayForDate or NSCalendar.dateBySettingHour.
fuzz addresses a strange issue on my x86_64 system:
[[formatter dateFromString:@"00:00"] timeIntervalSinceReferenceDate]
returns-31597200
. It should be0
. Maybe its a timezone quirk. Regardless, this compensation won't create any problems on systems that properly return0
.