Re: [Tsheetx-developers] Timesheets showing strange times

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

So, if I'm getting the correct message, the info in the database is correct,
but the ending date/time is mangled when printed?  And from the info below,
the totals are correct (the greyish numbers), but the ending date/times are,
again, mucked up.

Here's the flow of what happens when the data is read:

   1. If there is a valid duration, the ending times calculated from the
   start time and the duration
   2. the original end time is compared with the calculated end time.  If
   they don't agree, the calculated end time is written to the database.
   3. If there's not a valid duration, the duration is calculated from the
   beginning and ending times (this should only happen upon reading data that
   was entered with a previous version of the Timesheet System) and that
   duration is written to the database.

So, I'm going to guess that somewhere during the end time calculations, a
UTC to local timezone conversion is taking place.  There is a debuglog.php
file that helps to debug things.  Using it, will result in data being
written to a static file /tmp/php-debug.log. In, for instance, the file
user_action.php, you can find the following lines commented out:
require("debuglog.php");
$debug = new logfile();
$debug->write("status = \"$status\"
isActive=\"".$_REQUEST["isActive"]."\"\n");

I would suggest putting these lines within the fixStartEndDuration()
function to print out what the beginning times, ending times, and durations
are for each step within that routine to help narrow down exactly when this
incorrect conversion is happening.

Please report what you find out.

-Scott

On Tue, May 11, 2010 at 7:54 AM, Peter Lazarus <pal...@gm...> wrote:

>  Scott,
> thanks for the comments. I have done a little further investigation today,
> and the results are stranger than previously reported.
>
> The times for the start_time and stop_time in the _times database are
> showing correctly.  When I run the query get_time_records from common.inc
> the times and duration are also shown correctly, including the unix
> timestamps. (SELECT start_time AS start_time_str, end_time AS end_time_str
> , unix_timestamp( start_time ) AS start_stamp, unix_timestamp( end_time )
> AS end_stamp, duration FROM ts1_times) So that says to me that mysql is
> not stuffing up, nor is the start/stop clock panel in collecting and posting
> the times in the database.
>
> Now this is where it gets strange. In the daily timesheet display, all the
> Start times are correct. All the Stop times are into the next day. When I
> look at the code in daily.php, it looks like both Start and End times are
> being formatted exactly the same way.
>
> Now I just noticed in the paste of the web page below that the Total
> consists of two parts, and the "of nh nnm" is correct e.g second last row
> where start time is 16:32 and end time was set to 16:35, the duration of 0h
> 3m is correct.
>
> Does this suggest anything?
>
> Peter
>
>   Client Project Task Start End Total *Actions*  Lazarus Household Update
> Ubuntu Application Development 10:00 *7:35,12-May<http://localhost/tsng15/daily.php?&year=2010&month=5&day=12&proj_id=0>
> * 14h 0m* of 6h 35m* Details<http://localhost/tsng15/edit.php?client_id=0&proj_id=0&task_id=0&trans_num=33&year=2010&month=5&day=11>,
> Delete  Lazarus Household Update Ubuntu Application Development 10:00 *
> 8:21,12-May<http://localhost/tsng15/daily.php?&year=2010&month=5&day=12&proj_id=0>
> * 14h 0m* of 7h 21m* Details<http://localhost/tsng15/edit.php?client_id=0&proj_id=0&task_id=0&trans_num=34&year=2010&month=5&day=11>,
> Delete  Lazarus Household Update Ubuntu Application Development 16:25 *
> 7:33,12-May<http://localhost/tsng15/daily.php?&year=2010&month=5&day=12&proj_id=0>
> * 7h 35m* of 0h 8m* Details<http://localhost/tsng15/edit.php?client_id=0&proj_id=0&task_id=0&trans_num=31&year=2010&month=5&day=11>,
> Delete  Lazarus Household Update Ubuntu Application Development 16:32 *
> 7:35,12-May<http://localhost/tsng15/daily.php?&year=2010&month=5&day=12&proj_id=0>
> * 7h 28m* of 0h 3m* Details<http://localhost/tsng15/edit.php?client_id=0&proj_id=0&task_id=0&trans_num=30&year=2010&month=5&day=11>,
> Delete  Lazarus Household Update Ubuntu Application Development 16:34 *
> 8:00,12-May<http://localhost/tsng15/daily.php?&year=2010&month=5&day=12&proj_id=0>
> * 7h 26m* of 0h 26m*
>
> On 05/11/2010 01:20 AM, Scott Miller wrote:
>
>  In the forum at SourceForge, Peter Lazarus has reported the following:
>
> 2010-05-09 22:44:37 CDT
>
> I have tried the 1.5 and found something odd about the times entered into
> the system by the clock on/clock off process. When I started at 10am and
> ended at 1pm, the end time for that task appears as 4am the next day, and
> the duration is shown as 14hours. I set a clockon/off time for the default
> task, clocking on at 1am and off at 2am. The duration shows 1 hour
> correctly, but the end time is 5pm. Under config, the timezone is set to
> Australia/Melbourne, but no locale is set. So I just now in configuration
> changed locale to en_AU, with no change to the results. My system clock is
> UTC. My php.ini doesn't have intl.default_locale set, but does have
> date.timezone set.
>
>
>
> I have attempted to replicate the problem.  My TSNG config has been set to
> US/Central, the php.ini file had the date.timezone setting commented out.  I
> tried changing the php.ini setting to US/Central, restarted apache, but the
> dates/times entered via the clockon/off process were set as expected in the
> database, and then read correctly when the page was reloaded.  I then tried
> changing the php.ini to something completely different, “Europe/Zurich”,
> with no difference in date storage or retrieval.
>
>
>
> Since I was unable to replicate your problem, allow me to speculate where
> your problem may lie.  MySQL has the capability to attempt to convert
> dates/times automatically for you, and php can be configured to attempt to
> automatically convert dates/times when communicating with MySQL.  I would
> have to guess your problem lies either with the MySQL configuration, or
> within the communications between MySQL and PHP.
>
>
>
> -Scott
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>