feat: add default production time

[jakoballgaier]

• added environment variables
• created a utility to apply the default time to Date object
• updated PlannedProductionCreationModal

Description

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
• Copyright and license header are present on all affected files (TRG 7.02
• Documentation Notice are present on all affected files (TRG 7.07)
• If helm chart has been changed, the chart version has been bumped to either next major, minor or patch level (compared to released chart).
• Changelog updated (changelog.md) with PR reference and brief summary.
• Frontend version bumped, if needed (frontend/package.json, frontend/package-lock.json)
• Backend version bumped, if needed (backend/pom.xml)
• Open API specification updated, if controllers have been changed (use python script scripts/generate_openapi_yaml.py with running customer backend)

[tom-rm-meyer-ISST]

It's not working in local deployment. I locally fixed the frontend/.env.dockerbuild and added the DEFAULT_PRODUCTION_TIME to the docker compose setup for the frontend.

via npm works fine.

Please fix the local deployment. Further I would love if this feature is also considered during file upload (if no time is set, fallback to default).

[tom-rm-meyer-ISST]

Suggested change

	VITE_DEFAULT_PRODUCTION_TIME=$DEFAULT_PRODUCTION_TIME
	VITE_DEFAULT_PRODUCTION_TIME=\$DEFAULT_PRODUCTION_TIME

escaping missing for substitution script

[tom-rm-meyer-ISST]

Variable is not set in local deployment (local/docker-compose.yaml)

[tom-rm-meyer-ISST]

Maybe disputeable but I would put it to added. Please reconsider (but can also stay there)

[tom-rm-meyer-ISST]

bump not needed, 6.1.0 unreleased

[jakoballgaier]

Hi @tom-rm-meyer-ISST

thanks again for your feedback and for pointing out the issues with the local deployment. I would like to briefly align on two conceptual points:

1. UTC vs. local timezone handling

Currently, the backend operates in UTC, while the frontend works with the user’s local timezone. During Excel import, local timezones are also used. This means we are already mixing UTC (backend) and local time (frontend/import).

For the sake of consistency, would you prefer that we standardize everything to UTC (e.g. always store and process in UTC and only convert for display in the UI)? Or should we explicitly define that production times are interpreted as local time and only converted to UTC at persistence level?

I would appreciate your opinion on what you consider the cleaner and more consistent approach, so we can align on a clear rule going forward.

2. File upload in this PR or separate ticket?

Applying the default production time during file upload (if no time is set) would extend the behavior beyond the current UI-based flow.

Since the ticket scope focuses on introducing and configuring the default production time on application level (primarily affecting the default value in the UI), would you prefer to handle the import logic in a separate ticket?

This would keep the current PR strictly aligned with the defined scope and avoid mixing UI default handling with import logic.

Please let me know how you’d prefer to proceed.

[tom-rm-meyer-ISST]

Currently, the backend operates in UTC, while the frontend works with the user’s local timezone. During Excel import, local timezones are also used. This means we are already mixing UTC (backend) and local time (frontend/import).

For the sake of consistency, would you prefer that we standardize everything to UTC (e.g. always store and process in UTC and only convert for display in the UI)? Or should we explicitly define that production times are interpreted as local time and only converted to UTC at persistence level?

Hi @jakoballgaier,

Sorry for the delay (sick leaves, vacations, other deadlines). Thanks for raising the technical debt and providing alternatives!

1. Timezone Handling

I would go with standardizing the backend to UTC and convert to local time zone in the UI. Here again the question arises, if this should be handled as a separate PR. If you want to handle it in another pr, feel free.

2. This Pr or seperate ticket

I would keep it in this PR. I would have seen it also in the ticket even if I fully see your point that it's more on the dynamics.

Please incorporate and merge main (version bump needed). I'll handle your next changes prioritized to prevent further conflict resolving.