past time colour (pastBackgroundColor) on current day is off

[quivr]

past time colour (pastBackgroundColor) on current day is off

[jhoobergs]

@ezmegy The version on the developer branch is 2.1.1, so if you fix it and create a PR, I will create new release with the fix.

[jhoobergs]

@ezmegy Sorry for the late reply, so it only happens to you for 14:30 ? Or does it change when the zoom changes?

[ezmegy]

Hi, no worries. :)
I almost forgot about it myself because I turned off pastBackgroundColor and did not use it for a while.

Yes, so if I set this property to true, the colouring on the current day will either be until 14:30 or for the whole day, depending on the current time. (In example if now == 7:20 am, than today's column would be coloured until 14:30, if now == 16:15, than the whole column is coloured.)
Didn't test different time zones, mine was UTC+2 (now actually UTC+1 because of the daylight saving time).

[jhoobergs]

@ezmegy Are you using min and max time ? 14:30 seems so random 😄

[ezmegy]

I am, but It does indeed seem strange 😃 Random maybe too, but it's 14:30 every single time...

Anyways, I think I'll be able to debug it a bit tomorrow (the 2.1.1 build too), I'll let you know if there's any new info.

[jhoobergs]

@ezmegy I would certainly check what happens if you don't use min and max time, i think there is a calculation going wrong because of it.

[ezmegy]

Yep, that was it.

In WeekView.java changed this line:

float beforeNow = (now.get(Calendar.HOUR_OF_DAY) + now.get(Calendar.MINUTE)/60.0f) * mHourHeight;

to this:

float beforeNow = (now.get(Calendar.HOUR_OF_DAY) - mMinTime + now.get(Calendar.MINUTE)/60.0f) * mHourHeight;

I wanted to create a pull request but saw that in the fork it was already changed :)
Which is nice 'cause someone already found and made the change but also weird because I can't see these changes in the web repo (and probably some others since the line numbering is offset too: in the forked version I have this line on 903, whereas if I browse it in the original (not my fork) then it's 885)...

Anyways, the bug is fixed I suppose :D

[jhoobergs]

@ezmegy So it's working in the 2.1.1 release ?

[jhoobergs]

@ezmegy Doesn't seem to be fixed ? https://github.com/Quivr/Android-Week-View/blob/develop/library/src/main/java/com/alamkanak/weekview/WeekView.java#L885

[ezmegy]

That's also the strange part: no.

If set gradle to 2.1.1, this line would be 879 and still without the fix: the - mMinTime is missing...

(However, as mentioned when i forked it, the line was on 903 and did contain the fix.)

[jhoobergs]

@ezmegy Aren't you just looking at the wrong line ? In your fork it's the same https://github.com/ezmegy/Android-Week-View/blob/develop/library/src/main/java/com/alamkanak/weekview/WeekView.java#L885

at line 903 (or 904) it is indeed fixed https://github.com/ezmegy/Android-Week-View/blob/develop/library/src/main/java/com/alamkanak/weekview/WeekView.java#L904
but that's also the case in this repo
https://github.com/Quivr/Android-Week-View/blob/develop/library/src/main/java/com/alamkanak/weekview/WeekView.java#L903

[ezmegy]

Oh wow, my guess is this was a nice SublimeText cache bug :D
(I had it open in multiple tabs plus the clipboard, and it just kept displaying it at wrong line numbers, but restarting the editor solved it: 885 is the winner.)

Anyways, you're right, my fork doesn't contain that line either, so it shouldn't be in the latest version of the develop branch either.
(Not sure about any branches/versions on your side at this point, I'll leave that up to you to figure out :))

[jhoobergs]

@ezmegy Check version 2.1.2