Fix instrument schedule datetime-local fields showing midnight on Firefox browsers

[ankurjuneja]

Rationale

The instrument scheduler populated its two datetime-local inputs via DateFormat.format.date(...). In timezones whose Date.toTimeString() label contains a colon (e.g. Honolulu → (GMT-10:00)), jquery-dateFormat's parseTime() splits the
whole string on , gets more than 3 parts, bails, and pads the time to 00:00. Both start and end then collapsed to midnight, so start == end and the server rejected the save with "StartTime must be before EndTime" — failing the test on
the Honolulu TeamCity agent while passing elsewhere.

Fix: format the start/end fields directly to datetime-local's fixed yyyy-MM-ddTHH:mm wire format from the Date's own local fields, bypassing the buggy library path.

I think we need to fix the library path. Attached report.
DateTZBug.pdf

Related Pull Requests

Changes

[ankurjuneja]

The test is passing now in Honolulu TZ https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_External_Panorama_PanoramaAPostgres/4110030?branch=instrumentScheduleDateTimeLocalFirefox&buildTypeTab=overview&buildTab=tests&name=InstrumentSchedulingTest&expandedTest=build%3A%28id%3A4110030%29%2Cid%3A2000000055

[labkey-danield]

This looks correct to me, but I'll defer to Josh.
Should this target 26.7? Helping to keep the noise down in ESR builds is always appreciated.

[labkey-jeckels]

I agree with Dan that it would be good to patch in 26.7.

The fix here seems effective in fixing the test failure but incomplete. My Claude review came to a similar conclusion about patching parseTime() (finding #1 below) and found some adjacent issues. I recommend doing the larger fix.

Finding #1 — Medium — Incomplete fix / user-visible bug remains

webapp/TargetedMS/js/scheduler.js:94 and :107

• Issue: The same buggy DateFormat.format.date(<Date>, ...) path still drives the two display sites on this very page: the calendar tile labels (line 94, eventContent) and the hover tooltip (line 107, eventMouseEnter). On the affected browser/timezone combination, both still render 00:00 - 00:00. The same call also lives in webapp/TargetedMS/js/scheduleUtils.js:59 (ScheduleUtils.formatTimeRange) and resources/views/scheduleAllInstruments.html:48.
• Why it matters: The Selenium failure that motivated the fix will go green, but a user on Firefox in Honolulu still sees every reservation labeled midnight-to-midnight on the calendar and in tooltips. The stated intent — "datetime-local fields showing midnight" — is met; the underlying user-facing defect is not.
• Suggestion: Fix parseTime in the vendored platform/core/webapp/internal/jQuery/jquery-dateFormat.js — stripping the trailing timezone label before splitting (the function already does exactly that via .replace(/\s.+/, ''), just too late) resolves all of these at once plus every other platform consumer. Note jquery-dateFormat.min.js is served in production mode (jQuery.lib.xml:5-6), so both files need updating. This is what the review comment in the PR description is asking for, and it's the better lever; the local helper here is still worth keeping, since datetime-local wants a fixed wire format rather than a display format regardless.

Finding #2 — Medium — Pre-existing bug in the same feature, same symptom

webapp/TargetedMS/js/scheduler.js:618-619

• Issue: fetchInstrumentCosts is called two ways: with Dates from eventMouseEnter (line 105), and with the raw datetime-local strings from eventToSave.startTime/endTime after a save (line 691). jquery-dateFormat cannot parse the second form — its ISO matcher requires seconds (\d{2}:\d{2}:\d{2}), so 2026-07-26T08:00 misses it and falls through to the single-token char-index branch, which yields a zeroed time. Verified against the library:

  '2026-07-26T08:00'    -> "2026-07-26 00:00"
  '2026-07-26T08:00:00' -> "2026-07-26 08:00"
  

• Why it matters: The event-cost log row rendered after every save shows midnight for both start and end, on every browser and timezone — the identical symptom this PR is titled after, just via a different route. It's pre-existing rather than introduced here, but it's the same code path and the same user complaint.
• Suggestion: Have the post-save call pass Dates (new Date(eventToSave.startTime)) rather than the input strings, or normalize inside fetchInstrumentCosts before formatting. Fixing the library's parseTime alone does not cover this one — the failure here is the missing-seconds ISO match, a separate hole.

Finding #3 — Low — Test coverage

test/src/org/labkey/test/tests/targetedms/InstrumentSchedulingTest.java:184-193

• Issue: The test reads the field values and manipulates them (originalStart.replace("-03T", "-02T")), which implicitly requires T form and the right day, but nothing asserts the time component. Nothing pins the 8AM/5PM defaults.
• Why it matters: The helper could regress to emitting a wrong or zeroed time and the suite would stay green on a normal agent — the original failure only surfaced because of one agent's timezone.
• Suggestion: Add cheap assertions in the scheduleInstrument extra-steps block that the start field ends with T08:00 and the end field with T17:00.

Finding #4 — Low — Duplication / placement

webapp/TargetedMS/js/scheduler.js:388-393

• Issue: This module already has a shared helper namespace for exactly this (webapp/TargetedMS/js/scheduleUtils.js, which even holds the date-formatting helpers), and src/org/labkey/targetedms/view/instrumentCalendar.jsp:54-55 open-codes the same zero-pad-and-concatenate logic inline for the same two field names. The new helper is a third copy, private to scheduler.js. Also let pad = function(n) {...} allocates a new closure on every call and never reassigns — const, or hoist it out of the function.
• Why it matters: The next timezone/format bug has to be fixed in three places. Low impact, but the shared home already exists.
• Suggestion: Move it to ScheduleUtils.toDateTimeLocalValue and use it from instrumentCalendar.jsp too (with the date-only variant derived from it).

[ankurjuneja]

@labkey-jeckels the Finding 1 that is in attached bug report too, the two files that need the change:

• platform/core/webapp/internal/jQuery/jquery-dateFormat.js (this is fine)
• platform/core/webapp/internal/jQuery/jquery-dateFormat.min.js

my question is for the min.js-

jQuery.lib.xml has compileInProductionMode="false"

I need to make change to the min file too for production, is that OK?

[labkey-jeckels]

@labkey-jeckels the Finding 1 that is in attached bug report too, the two files that need the change:

• platform/core/webapp/internal/jQuery/jquery-dateFormat.js (this is fine)
• platform/core/webapp/internal/jQuery/jquery-dateFormat.min.js

my question is for the min.js-

jQuery.lib.xml has compileInProductionMode="false"

I need to make change to the min file too for production, is that OK?

Yes, I saw the PDF and that it was essentially the same thing. And yes, patching both flavors of the script seems correct.

[ankurjuneja]

transferred to 26.7 - #1266