Clearer timer errors when the start time is in the future

You can start a timer a little late. Open Start new timer, set Start date & time to when the work actually began, and Portime counts from there. That is useful on a day when you remembered the client call only after you hung up.

What you cannot do is start a timer in the future. A timer measures time that has already started. If the date and time you pick is later than now, Portime refuses the start. That rule did not change. What changed is the message you see when it happens.

What you see now

Set the start to tomorrow, or even two hours from now, and submit. The dialog stays open, no timer is created, and a single toast tells you why:

Timer start date and time cannot be in the future.

If Portime is in French, the same moment shows:

La date et l'heure de début du minuteur ne peuvent pas être dans le futur.

Change the start back to now, or to a time that has already passed, and start again. You do not have to guess which field was wrong, and you do not have to close the dialog and begin over.

If the date and time cannot be read at all, the message is just as direct. In English: "Invalid timer start date and time." In French: "Date et heure de début du minuteur invalides."

Why the old message was hard to use

The check itself was already there. Portime knew the start was in the future and already had a sentence ready in both languages. In day-to-day use, especially on the live site, that sentence did not always reach you.

Instead of a correction, the toast could look like a system failure: a long, generic line that did not mention the start time at all. The dialog and the timer could also stack the same failure, so it felt louder than it was. The practical result was the same either way. You knew something had failed, and you did not know what to edit.

That is a bad trade for a rule this simple. "Not in the future" is a one-field fix. The message should say so, in the language you are already using.

French is the real message, not a fallback

Portime's interface is English by default, with French available from the language switcher. These timer messages follow that. They are written in messages/en.json and messages/fr.json, and the screen reads the catalog for your locale.

The French lines are French. They are not the English sentence left in place, and they are not the internal name of the message. Switch to French, start a timer with a future date, and the toast is the sentence above. Switch back to English and you get the English sentence. Same rule, same dialog, same next step: pick a start time that is not ahead of now.

A few related French lines were tightened in the same pass, so "sous-client" is used consistently when a project does not match the client and sub-client you selected.

The same idea, beyond the start time

A future start was the obvious case, because the failure was common and the correction was obvious. The same gap showed up in other everyday actions. You would do something Portime could explain, and the toast would still hide the explanation behind a generic production error.

Those paths now return a stable reason, and the screen turns that reason into the translated sentence. You should see a clear toast, once, for situations like these:

• Too many timers. You can run at most 10 timers at once. In French: "Vous ne pouvez pas lancer plus de 10 minuteurs en même temps." Pause or discard one before starting another.
• A timer that is already gone. If you pause, resume, discard, or save a timer that no longer exists, Portime says the timer was not found, instead of failing silently or with a system paragraph.
• A project that does not belong with that client. Saving a timer, or saving a time entry, against a project from another client or sub-client names that mismatch. In French, that message now says "sous-client", not a mix of French and English.
• A task that cannot be saved as entered. Creating or editing a task still checks the title, status, priority, client, project, and assignees. When one of those is wrong, the toast uses the matching sentence, in English or French, such as "Title is required." or "Le titre est obligatoire."

Unexpected failures still use a short generic line, "An error occurred." / the French equivalent, rather than a long technical paragraph. The point of this release is the cases Portime can explain: you get the explanation.

Loading a task, adding a comment, and opening assistant history follow the same habit. If those fail, you see the short message already written for that screen, not a dump of an internal error.

What to do when a timer will not start

1. Open Start new timer.
2. Check Start date & time. If it is later than the current minute, move it back. Leave it empty to start from now.
3. Read the toast. If it says the start cannot be in the future, that is the whole problem.
4. Submit again. The dialog stays up until the timer actually starts, so your client, project, and description are still there.

Backdating still works. If you began the work at 9:40 and you are logging it at 10:15, set 9:40. Portime accepts that. It only stops you when the start is still ahead of the clock.

A small change with a practical result

None of this adds a new way to track time. It makes the existing rules readable. A future start is rejected with one sentence, in the language of the app, and the same treatment covers the other mistakes you are likely to hit while starting a timer, saving it, or editing a task.

If you work in French, you do not have to interpret an English error or a blank technical one. The message is already the one you would want to read: the start date and time cannot be in the future.