ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Human readable and writable times (Feature #160)

Added by Aleksey Zapparov at 2011-02-08 05:13 pm. Updated at 2012-09-18 06:28 pm.

Status:Open Start date:2011-02-08
Priority:Normal Due date:
Assignee:- % Done:


Category:Time entries
Target version:-
Remote issue URL: Affected version:


Right now time (estimated, elapsed, etc) is entered in hours. So for example 2.5 means 2 hours and 30 minutes.
It will be very great to be able to enter time as "2h 30m" or "4w 3d 2h 1m".
Of course there should be n option to choose how to output times in views:

  • Normal (e.g. 1d 2h 30m)
  • In Hours (e.g. 8.00)

Also there should be a configuration option to set how much hours in a day (8 by default).


Updated by Aleksey Zapparov at 2011-02-08 05:57 pm

Related issue:

Also I was "too hot" about "2h 30m" - it's already supported. But I believe that we have to allow add days and weeks too. So there should be config t set how many days in a week, and how many hours in a day. And of course the main and very necessary thing is to make output more user-friendly.

Updated by Eric Davis at 2011-02-08 10:39 pm

  • Category set to Time entries

Updated by Felix Schäfer at 2011-02-09 02:20 pm

Is hh:mm an accepted format for durations?

Regarding the ability to add greater time lengths, for example days and weeks, how often do you use them, and where do you input so much time that you'd need it parsed? I've never had an issue that took up more than 4 hours, so I'm a little puzzled.

Updated by Aleksey Zapparov at 2011-02-09 02:32 pm

Felix Schäfer wrote:

Is hh:mm an accepted format for durations?

Yes, this format is a great one. But some of people like to have more "easy" to understand formats. So for example it's easier to read and estimate in the head how long is that if it's written like "2d 3h", then "19:00".

days and weeks, how often do you use them

If we talk about me, then sometimes. But if we talk about other people then it depends on too many factors.

and where do you input so much time that you'd need it parsed? I've never had an issue that took up more than 4 hours, so I'm a little puzzled.

Well. First of all, an issue can have sub-tasks, so total amount of hours of one issue can be pretty much big. Also we have to keep in mind, that ChiliProject is a generic "project management system", not "a software project management system". So some of people use it as a project management for their different types of tasks, e.g. "replace all UTP wires with fiberglass in the Joe's cabinet".

Updated by Eric Davis at 2011-02-09 08:03 pm

One problem will be with the configurable amount of time in each (week, month, year, etc). This is a place where it's really easy to spend a lot of time without much additional benefit:

  • week versus work week
  • holidays
  • leap years
  • office hours
  • half days
  • vacation time
  • split shifts
  • ...

If we can keep to a standard length of time then this would be a little easier. Day is 24 hours, week is 7 days, month is 30 days, year is 365 days. But even here we have to make assumptions (no 28, 29, or 31 day months or leap-years).

Personally I prefer a simpler system that is easy to understand than a complex one that is difficult to configure. But that's just my opinion, I'm open to proposals/ideas/code for this.

Updated by Aleksey Zapparov at 2011-02-09 08:32 pm

My idea was a little bit more humble than months, years... I thought week will be the largest amount. So there will be a configuration option to give admin set how much hours in a day and how much days in a week. So no point for extra complex leap years, or holidays. So right now I see that it would be better to achieve this as follows:

  1. Output of the time should use some standard helper, so all places will have time formatted with absolutely same format
  2. By default this helper should output date as hh:mm
  3. Admin will have ability to choose format of how to display this values
  4. If chosen format requires some additional settings (e.g. # of days in a week) then additional settings are shown.

After all. If I am the only single person who miss this feature (which is the standard de-facto in some of project management systems afaik), then all what is needed is to fix first bullet of the list above, so I'll simply write a plug-in which will extend standard functionality. So then when I'll write a plugin, if it will become popular we'll be able to either move it to the standard shipping or merge it's features in the core.

Updated by brendan edmonds at 2012-01-15 01:18 am

From what I understand, when you log time, its the actual amount of hours you spent doing the task. Not the total amount of hours including out of business hours, holidays, etc.

If you need to enter more than 24 hours for one time entry, put your time in, and HAVE A BREAK.

But in saying that I tend to agree the way the time is formatted is very confusing, and needs to be fixed in the format hh:mm.

I am using redmine, has this been fixed in chili?

Updated by Rolando Valdivia at 2012-09-18 06:28 pm

I agree about the format "hh:mm".

But remember that the time entries relates the time spent in a task in a day.

You can spend up to 24 hours per day in a task or multiple tasks.

Can you work 1w in a day?

If you generate a report you will say: "I spent 3w this week" or "I spent 9w this month"

The system should not allow to log more than 24 hours per day.

Also available in: Atom PDF