Re: [Tsheetx-developers] Feedback on branches/txsheet-2.0-demo

[Scott M. <Sco...@pr...>]

Yes, however removing end times makes it much more difficult to collect
a blocks of times from the database. But, if we also make the change to
not allow individual time entries to cross date boundaries, then that
problem goes away and we can eliminate end times completely.  This would
certainly be fine with me...

 

-Scott

 

________________________________

From: David Thompson [mailto:tom...@us...] 
Sent: Monday, November 15, 2010 3:45 PM
To: tsh...@li...
Subject: Re: [Tsheetx-developers] Feedback on branches/txsheet-2.0-demo

 

Scott,
I think you're right, we want to just store UTC in a neutral way in the
DB, but I want to remove end-times, we introduced duration to replace
these.
Dave
 

________________________________

Date: Mon, 15 Nov 2010 15:39:32 +0000
From: sco...@gm...
To: tsh...@li...
Subject: Re: [Tsheetx-developers] Feedback on branches/txsheet-2.0-demo

With changes as large as this, perhaps this would be a good place to add
the needed date/time storage change to the database?  

Currently TSNG can not handle functioning across different timezones
other to simply ignore that other timezone's exist.  To handle things
correctly, here's what needs to happen:

1.  start/end times need to be stored using unix timestamps, I suggest
using 64 bit fields in the database so that when the timestamps begin to
use 64 bits, we won't have to touch the database.
2. the times stored need to be stored in UTC format, each user could
then locate themselves in a timezone, and PHP should be able to convert
their times to UTC time and back.
3. when data is pulled out of the databases, conversions to local time
should be performed for entry forms, but probably not for reports.

That's all that's needed for the system to be able to work correctly,
but the issue of user configurations needs to be tackled too. And let's
not forget about the elephant in the room, writing the script that
converts the existing time/date data into this new format; this may seem
like a relatively trivial task, but I believe there are some very tricky
issues to overcome: DST, the possibility that some worker's are in
different time zones within the same database, I'm sure there are
others.

#1 above eliminates the issues that can be caused by the database system
attempting to "help us" by doing time/date manipulations before handing
PHP the data.
#2 and #3 allows TSNG the ability to function correctly across different
timezones

Looking forward to seeing your work Mark!
 BTW, within a branch such as this, feel free to break things, that's
what a branch is for :-)
As for compatibility, as long as we can migrate the database from the
current system to the new one, you don't need to worry about
compatibility. 

-Scott