A stored timestamp and a calendar-day label answer different questions. In Curricula, elapsed work and the date shown in the logbook use different calculations.
Calculate duration from the recorded interval#
The timestamp calculation starts with end minus start, subtracts paused time, converts the result to hours, and clamps it to the application's range.
Formatting those timestamps into strings first would add an unnecessary dependency on locale and display format. Numeric instants are the appropriate inputs for elapsed duration.
Choose the timezone for the logbook date#
The source explicitly formats time with the Asia/Manila timezone and uses the same timezone for date keys. This prevents a UTC calendar boundary from silently determining which local workday receives the log.
A person can be recording work on one local calendar date while its UTC representation belongs to the previous date. The date key therefore needs the intended local calendar context, not just a slice of an ISO timestamp.
State the manual-entry rules#
Manual HH:MM input is parsed with valid hour and minute ranges. The end must be after the start, and the duration is rounded and capped at nine hours.
That describes same-day input. An overnight interval cannot be represented correctly by simply subtracting those two time-of-day values. Supporting overnight work would need a date-aware input model rather than weakening the existing check.
Keep policy and arithmetic separate#
Subtracting paused time is arithmetic. A nine-hour cap is an application policy. Making both explicit helps a reviewer identify which behavior needs a calculation fix and which needs agreement with the intended workflow.
The source establishes those rules; it does not prove that the cap satisfies every internship program. That belongs to the institution's requirements and the product's deployment context.