Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); fix(runtime): use local timezone for turn-tail date by Astro-Han · Pull Request #540 · apache/maka · GitHub
Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes#538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily ReviewclassName + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.
Closes#538.
…lt TZ path
- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
passed it, so it only widened the public API for tests. Production now
formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
(getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
calls the fragment WITHOUT a timezone arg, locking the real default
production path (desktop/CLI never pass timeZone) instead of a test-only
arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
value now depends on the process timezone.
Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into mainJul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant

@Astro-Han