Import and End Date problems (not a date format issue)

GanttProject Desktop Support
1

For a tool that promotes itself to be easy and simple to use, it is incredibly obtuse when it comes to dates for no seemingly good reason. Importing a CSV with mapped out Begin date and End date, it inexplicably launched some of the entries a full year ahead from 2026 end to 2027 sometime. And pretty much every entry was off by several days or months upon import compared to the CSV. This has cost me dearly as I was expecting a simple import process and ran out of time for an important academic deadline and had to post a seemingly incompetent Gantt Chart.

After, in frustration I started playing more with the tool to figure it out as I’d like to see if it would be viable to use for life. To my surprise I discover further obtuse problems with the date system. I created a blank Gantt and added blank tasks in it. When I go into the properties of the tasks, all the End dates are greyed and I can’t see a way to enable them at all. GRRRrrrrr. This tool is getting frustrating and it is only at a glance easy to use, but it is all a deception. You must address these issues and truly make this user friendly (I paid for it btw, because it looked so good initially).

I read in another thread that Duration takes priority. This is so counter-intuitive to how the world works. Most people know the start and end dates for their tasks and projects. Then simple maths of subtraction between the dates should do the rest. That would make it a forever useful tool. And under no circumstances should any default behaviour disallow the user from playing around with dates ie. greying them out etc. Who sits there and counts Duration manually?

(Apologies for the tone, but this has seriously frustrated me for the past 2 hours, enough to make an account here and post this)

Here’s my csv so you can see what I mean:
final_wbs_dates_ddMMyyyy_fix.csv (5.3 KB)

PS: Why are there additional Start and End fields with default Text type?

2

It seems that the reason is that the import process calculates the duration literally as the difference between two dates (exactly as you suggested by the way):

Then simple maths of subtraction between the dates should do the rest.

and then applies the result duration to the task start dates, taking into account the weekend days (in the default project document, Saturday and Sunday are non-working weekend days). Thus, the tasks become longer, because every weekend that they cross adds 2 days.

To fix it, you can create a project where the weekend days are working and import the CSV file into that project. An example is attached.

I paid for it btw, because it looked so good initially

Please send an email with your payment details to [email protected] to request a refund.

Have fun.
SetupTheWeekendDays.gan (30.8 KB)

3 
ID,Name,Begin date,End date,Duration,Completion,Cost,Priority,Coordinator,Predecessors,Outline number,Resources,Assignments,Task color,Notes,Web Link,Start,End,Parent
------------------------------------------------------------------------------------------------------------------------------------------------------^^^^^^^^^^

That’s why.

4

Hello, thanks for the reply.
If this is a “feature” not a bug, then it needs to be addressed I think. It seems to be causing every other user issues. As a Quality Engineer, from my experience I would say one solution might be that at creation time, a prompt should come up asking the user if he wants weekends or not. Or even easier, on the Import wizard there should be an option to set/convert the project, or if not, allowing the Import to go straight to a new project with that setting. Or even double-easier, the Duration calculation subtraction algorithm should check the config setting for the project and then either calculate a duration with or without weekends, without the user having to even know that there’s a hidden setting for projects whether to include weekends or not.

I do not want a refund. I think this is a highly complex, yet minimalist product built out of passion and love and I want it to be better. Unfortunately, the way to do that is to be critical and provide feedback. (trust me, I know a thing or two about thankless jobs as a QA).

Regarding the Start and End fields, that was not an explanation. I still do not understand. What is the purpose of Start and End, in addition to Begin date and End date? It is not self-explanatory and confusing instead, especially when digging to discover that Start/End are configurable fields that can also be set to Date types but default set to Text… Or perhaps my brain has left me after not sleeping for 16h to submit a Master’s deadline…

5

However, perhaps even more alarming is that the Begin date doesn’t match up either for any of the fields. This I really do not understand.

2025-04-25_15-01
2025-04-25_15-01267Ă—1047 64.8 KB

6

Thanks for your time and valuable ideas.
The weekend setting is not hidden, it appears in the New Project wizard and in Project > Properties > Calendar. Yes, the import algorithm takes it into account, that’s why it works the way it does.

They are specified as columns in your CSV file. I pointed to the place where you can find them. I don’t know how can I explain it better. You created two columns, why shall we ignore them, just because their names are “Start” and “End”?

Unfortunately, the way to do that is to be critical and provide feedback. (trust me, I know a thing or two about thankless jobs as a QA).

I hope you will find some time to learn to be slightly more polite after defending your thesis. Good luck with that!

7

Because a task can’t start on weekend day if weekends are configured as non-working days.

8

That CSV file with those Start and End fields was created out of an Exported blank new project from the software which I used as a model to see what fields are available. I did not just randomly create them. It’s good to know that I can insert custom fields though if I ever need to?

9

Summarizing, it is certainly a usability issue, because we can’t take a decision about the weekends based only on the CSV file contents. It seems to be a good idea to show the current weekend settings during the import to let the user check if they match their expectations. Thanks for pointing at this issue.

1 Like
10

Yes, I am sitting here thinking about it and there’s definitely something not right about the logic around this:
Project set to:
No Weekends(normal world) + Start/End dates = Overshoot Duration calculation :-1:t3:
Yes Weekends(abnormal) + Start/End dates = Duration calculation technically correct BUT in the real world almost nobody works weekends so inflated Duration number. :-1:t3:

It could lead to a PM thinking there’s tons more resource working days left for planning or even overcharging for the total amount of working days being wrong in reality. ie. charging for non-working days in the real world. Also leads to complicated manual calculation where you would now have to somehow subtract weekends from the total Duration, despite your End date being correct now in the software…

So I don’t think you can escape the fact that the Overshoot needs fixing.

Perhaps either let the user select whether to calculate Duration inclusive of weekends or exclusive, if possible, as a setting at Import level and in every Task Properties when setting the dates for it. Tasks may exist which would independently require working overtime at the weekends for example or something too.

Alternatively, both could be done. As knowing both the Duration with weekends and without in a project is useful for schedule tracking. (ie. knowing how many days have passed in the year vs. knowing how many working days left in the year). So perhaps a new field could be introduced? (Working Days and Duration as fields)

Could you also explain this other anomaly please?

I created a blank Gantt and added blank tasks in it. When I go into the properties of the tasks, all the End dates are greyed and I can’t see a way to enable them at all.

11

Most likely, it is a summary task.
You may want to read the FAQ: READ ME FIRST. FAQ and Search, in particular, an article about GanttProject scheduler that is linked from there: GanttProject Scheduler Explained - GanttProject Docs

12

When I go into the properties of the tasks, all the End dates are greyed

Or did you mean this?

image
image1617Ă—768 74.2 KB

The end date is calculated from the start date and duration. If you want to calculate duration from the start and end dates, choose “duration is calculated” in the “scheduling options” dropdown.

1 Like
13

Oh it wasn’t clear that that blue label looking thing was a drop-down box at a glance. I thought it was some tooltip. My bad.

This route does seem to calculate Duration correctly (ie. No Weekends project + Start/End dates = correct working days amount calculation (however not clear from info label that this Duration value is without weekends)).

So how come on Import of tasks with Start/End dates it’s not doing it correctly?

14

What we see in the CSV:

Stakeholder interviews,05 07 2025,25 07 2025

What can we derive from this data? That this task duration is 20 days. Can we be 100% sure that those 20 days are the calendar days, with non-working weekend days included? No. We can’t be sure that those 20 days are only working days either.

At the moment GanttProject just relies on the weekend days setting in the project where you import to, assuming that if you want to import your data “as is”, meaning that 20 days are 20 calendar days, no matter if they are working or not, you will set up the target project to have no weekends. As I said before, it makes sense to make the current project settings more visible, so that the user was aware of them.

15

What can we derive from this data? That this task duration is 20 days. Can we be 100% sure that those 20 days are the calendar days, with non-working weekend days included?

This question is flawed. Because ironically, you are making the opposite assumption of being sure that a project is a non-weekend one and setting that as default (which is a fair assumption to make). But it is also a fair assumption to make that people want to import Start and End dates without hassle and I would say this even supersedes every other issue we discussed.

It is much better to explain to a user why their Duration days is so “high” (if they even care about that; and they can probably figure that out by themselves anyway) rather than having an imported project blow up in such a buggy, non-sensical way because of a superfluous setting which they can’t figure out by themselves. It is just a bad logical design.

What can we derive from this data? That this task duration is 20 days.
This is the only statement that the software needs to make. The rest of the questions are fluff. It is much less inconvenient for a non-expert user to approximate total working days from a total Duration than it is to have the project schedule be wrong. It’s a matter of priority, so I advocate that the default setting be changed to include weekends for calculation purposes, at least until a better way is found (you won’t unless you add an additional prompt/question at Import time).

Let me user story this:
As a new user, I want to import a simple project CSV which contains Start and End dates and have that represented on the chart accurately.

Can we be 100% sure that those 20 days are the calendar days, with non-working weekend days included?
Additionally, you’ve already asked these 2 questions, why not a third? If you’re not sure, why not ask the USER? He knows!
Add a setting at import time explained with a tooltip of implications. Or just don’t ask those 2 questions at all and stop at the statement as explained above and ignore the project setting completely for this calculation. That weekend setting would only be useful for some kind of burn-down chart or cost calculation anyway so it should only be applied to a calculation there specifically, and sporadically in limited situations. Automatically making this lower priority than having an accurately scheduled Gantt based on user data - which this needs to be the case at all times.

TLDR: if you have to compromise, it takes precedence in priority to have an accurately scheduled Gantt with possibly the wrong Duration value due to assumptions, instead of having a badly scheduled Gantt with accurate Duration days. In the same way that the User dates should be sacred and fixed, irrelevant of weekends or not. Make it the user’s responsibility to sanitise his data, not yours! You can always add a post-Import setting to ignore weekends. Much better solution.

As it stands you are going to keep getting threads like this ad nauseam, even if you just better display that setting (you will fix the symptom, not the root problem) because to any user, once they input data and the data is not represented as they expect, they will think the software is bugged. I repeat: Make it the user’s responsibility to sanitise his data, not yours.

16

Follow-up question: If I set the Project to have weekends so that I can import “correctly”, how do I then go about excluding weekends as working days after?

17

Project > Properties > Calendar.

18

What will this do to the Duration and Start / End dates? Will they be affected?

19

GanttProject will keep the duration and will change the end dates appropriately.

20

Wait, what? Why? So I’d be back where I started with erroneous Start and End dates? Why are you giving so much priority to Duration as a concept, instead of Start and End Dates which are the general thing everyone works with?