Thanks yeah, that would be the way to go, in most cases. Unfortunately, most employers use in their business the official local time of their country instead of UTC. And when there is a due date at 10, a software saying it is at 11 (because it counts only the seconds within working time declared by the user, mapping every segment of checked expenditure to them, so the time-related criteria in urgency calculation is realistic), well, it can turn out as a annoyance for the user to have to calculate around it when entering tasks and planning their time model. That is why I chose local time. I the developer may have to solve these issues, not him.
| [reply] |
There's nothing preventing the users from entering times/dates in local times. Convert the entered times/dates to UTC (or, possibly to a "raw" time value), perform your logic, then convert back to local time.
I think that Date::Calc] will be very helpful to you.
| [reply] |
Hi RonW, I am already using Date::Calc heavily, as you can see in my code above containing calls to MkTime and Add_Delta_Days. :-)
By local <=> UTC time conversion, I am afraid the DST switch issues would just bite me somewhere else. Somewhere in the system I just have to deal with the regular plus and minus DST hours affecting the user's actual schedule after all. Because knowing how long it effectively takes between point a and point b of time, from the users perspective, DST is a condition the software must handle instead of evening it out by UTC conversion. This is the price for having his planned private off time explicitly excluded from time-related calculations.
| [reply] |