In the timesheets sections there is still one week
missing (the first week of this year). Also all
following weeks are shiftet by one week, so that always
the wrong week is displayed. I think this has to to
with the 53. week of the last year (week one of a year
starts with the first thursday of the year).
This bug is still present in the new 1.2.6 MAX release.
Logged In: YES
user_id=608879
It has to do with week 53, absolutely.
Problem is, I cannot reproduce this failure. You can try on
the demo site (http://opt.tiempo.nl) and you will see all
weeks, and nothing shiufted. Unless you're taking another
route to get there.
Do you mind sharing which menu steps you do in the menu's to
get to the incorrect behaviour?
Thanks, Martin
Logged In: YES
user_id=768400
I get this error via: People->Timesheets then there is already the
incorrect week displayed (1 week shifted). When I use the "Previous"
links at week "Jan 10, 2005" it skips directly to "Dez 27, 2004".
Maybe this has something to do with the german locale I am using?
See also the bug report about the missing locale from me... (okay
this is just a blind shot :)). Or just that I use a complete german
system (apache and php are localised also).
I will try setting up a fresh new installation of the new OPT release (I
just upgraded our current installation which already contained the
patches I reported).
Logged In: YES
user_id=768400
Okay I found the place where the error occurs, but since I'm
no PHP programmer I can't say what exactly is wrong :-}
The problem is the function: get_date_from_week in
date_funcs.php. This always returns a date one week later
than apropriate which in turn is then used as starting point
for the strtotime function.
Btw: it's not necessary to calculate the $week_start every
loop, is it? :)
Logged In: YES
user_id=608879
Wild guess, but perhaps it's a good one. I Googled for
locale german and date functions and saw from the php manual
an interesting comment: see e.g. http://nl.php.net/strftime
<quote>
Note: %G and %V, which are based on ISO 8601:1988 week
numbers can give unexpected (albeit correct) results if the
numbering system is not thoroughly understood. See %V above
and example below.
</quote>
OPT uses a date function like:
$is_weekone = strftime("%V", $first_day) == 1;
I only looked at this briefly, but it looks like the example
in the link above is showing the %V variable and the
different results you get with different locales.
Well, as I plan to rework the whole language stuff handling
for a next major release, I'm not sure how much time I
should spent on fixing this, as locale support is "less
optimal" in OPT right now anyway.
Let me know what you find with a fresh install and I'll give
this some more thoughts.
Martin.
Logged In: YES
user_id=768400
Well, I dirty hacked it for now: i just subtract 2 rather
than 1 (return $week_one_start+(3600*24*7*($week-2)); ).
This works for me, but I don't know about the implications...
Frankly I think this is all a bit overcomplicated, maybe due
to prior versions of PHP or so ... next week I might have
time to install the fresh version and maybe try to learn a
bit about date calculations in PHP. Might be that I am just
fastidious from my usual programming language Java :)
Logged In: YES
user_id=608879
As I cannot reproduce this and I know the locales sections
is sub-optimal, I've decided to close this report. If anyone
experiences a similar issue, please re-open or submit a new bug.
Martin