Re: [Tsheetx-developers] Timezones, time adjustment and UTC

[Peter L. <pal...@gm...>]

Scott, Mark,
so we are gathering some requirements here, which is good. Not only 
should tsng handle multiple timezones, but also daylight saving. And 
user rates. There could be multiple user rates per person as well. One 
of the reasons I introduced a user type "contractor, employee" was to be 
able to see how much profit a consulting job was making. For example the 
contractor costs me $x and I charge him out at $y, and I can then see 
the difference. Mark is also right, there is a need for one person to 
have different charge rates for different tasks or projects. And some 
charging is done on an hourly basis and some on a fixed 8 hour day.
Peter

On 09/21/2011 08:15 AM, Mark Wrightson wrote:
> Hi Scott,
>
> You are right that the management reports don't currently do anything 
> with clocking times other than durations but looking forward I can see 
> a requirement for instance that allows reports to be generated that 
> show users that are clocking hours outside the "usual hours of 
> business".  If a manager wants to create a profile that highlights 
> erroneous clockings, timezone becomes an important factor.
>
> Information can always be diluted at a later stage, but if it is lost 
> at the initial stage it can never be recovered.  tsng could be written 
> such that timezone is never accounted for, but if the db contains the 
> information, the system is at least capable of adding that 
> functionality at a later date.
>
> I'm an advocate of the "design for the future principle" - as in 
> consider the future potential the system could have and put some of 
> the building blocks in place that will facilitate that expansion.  The 
> expansion may never happen but at least the capability was available 
> without a significant redesign.
>
> As we are discussing clocking times, I also think the user rates 
> should be part of the individual clock times, as a individual users 
> rate may change over a period of time, but the old clockings should 
> not neccessarily be updated with the new rate. .../but thats another 
> discussion!/
>
> Cheers
> Mark
> _____________________________________________
>
> Mob:  07725 695178
> Email:ma...@rw...
>
> On 20/09/2011 19:40, Scott Miller wrote:
>> But it being "lossy" is not necessarily a bad thing.  The database 
>> itself doesn't need to know the timezone.  It's only the user looking 
>> at the data that may care about when during the user's day a task 
>> happened.  Taking UTC time and converting it to the current user's 
>> timezone may be better than your proposal; it's way to early in the 
>> discussions for me to predict which will win out.
>>
>> If we consider the real "ends" that a timesheet system provides, 
>> the management reports that are generated later, they really don't 
>> care when the start/stop times were, they only care about the amount 
>> of time that was spent within a given time frame.  So all the 
>> monkeying about with timezones etc. is only needed to keep the end 
>> user happy that their data is entered correctly.  Unfortunately this 
>> makes up 90% or more of the use of the system.  So, which ever way is 
>> most efficient, in terms of maintainability plus user experience, at 
>> creating a "good" experience for the end user is the one that should 
>> "win".
>>
>> -Scott
>>
>> On Tue, Sep 20, 2011 at 12:48 PM, Mark Wrightson 
>> <ma...@rw... <mailto:ma...@rw...>> wrote:
>>
>>     Hi Scott,
>>
>>     Some work does need to be done to confirm this, but I think all
>>     of the logic could be quite neatly encapsulated in a single
>>     TaskTime object class.  The conversion between w3c dates, utc
>>     dates and locale dates is quite easy and could be made into
>>     functions of a TaskTime object relatively easy.
>>
>>     Work to confirm this would be needed through.  At least if the
>>     timezone is stored, the database contains all of the required
>>     data to show whatever you need.  whereas storing as utc is
>>     'lossy' in that we lose the timezone information.
>>
>>     Cheers
>>
>>     Mark
>>
>