Time Tracking modal displays inaccurate "Date Started" when setting days or weeks in "Time Spent" field

Issue Summary

The "Date started" value within the Time Tracking modal inaccurately reflects the input provided in the "Time spent" field when users input days or weeks. The discrepancy becomes evident, for instance, when setting time in days or weeks, causing the "Date started" field to display dates inconsistent with the intended time frame.

Steps to Reproduce

1. Open an issue.
2. Click on the Time Tracking field to log work.
3. Modify the "Time spent" field using values such as 1h, 10h, 1d, 1w, etc.
4. Observe the automatic adjustment of the "Date started" field (e.g., setting 1w results in the "Date Started" field showing a date 2 days earlier).

Expected Results

Implement a mechanism that integrates configurable shifts (office hours) into the calculation. Allow users to define their work hours within their accounts or enable the organization to establish a default shift (e.g., 8 am to 5 pm). Furthermore, consider the user's timezone during these calculations.

Example (assuming 1d equals 8h, and a shift from 8 am to 5 pm):

Given the current date and time: Thu, 17 Aug 2023 13:00:00

Time spent: 1d

Date started: Wed, 16 Aug 2023 14:00:00

Actual Results

Whenever you open the Time Tracking panel to log work for a ticket, the system captures the current date and time. This captured information serves as the reference point for calculating the "Date started" field, based on the input provided in the "Time spent" field. For example, if the time spent is logged as 15 minutes, the "Date started" is set to the current date and time minus 15 minutes. Similarly, if the logged time is 1 hour, the "Date started" will reflect the current date and time minus 1 hour. When using days or weeks, the time duration is always translated into hours based on your Global Time Tracking settings. As an illustration, if you have configured a workday as 8 hours and a workweek as 5 days, designating a time spent of 1 day would translate to the "Date started" being set to the current date and time minus 8 hours. Similarly, a time spent of 1 week would lead to the "Date started" being calculated as the current date and time minus 40 hours. We do acknowledge that this calculation might not be exact; however, currently, this approach is the most feasible, given the unknown nature of user shifts and potential office hours.

Example (considering 1d equals 8h):

Given the current date and time: Thu, 17 Aug 2023 13:00:00

Time spent: 1d

Date started: Thu, 17 Aug 2023 5:00:00

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available.