github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-21 02:32:22 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[PR #1807] [MERGED] feat: add time display with configurable format (12h/24h) to non-relative date formats #5238

New Issue
Closed
opened 2026-04-16 13:31:34 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-16 13:31:34 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/go-vikunja/vikunja/pull/1807
Author: @Copilot
Created: 11/12/2025
Status: ✅ Merged
Merged: 11/13/2025
Merged by: @kolaente

Base: main ← Head: copilot/update-date-display-settings

📝 Commits (7)

  • 831943f Initial plan
  • 3fb0142 feat: add time display to non-relative date formats
  • c98d690 feat: add configurable time format (12h/24h) for non-relative dates
  • c7ffafe fix: remove HH:mm placeholder from date display options
  • 8509f9c fix: use explicit 12-hour format to respect user preference regardless of locale
  • 1346769 fix: add timeFormat default value in all IFrontendSettings initializations
  • 01a953a default to 24h

📊 Changes

9 files changed (+140 additions, -22 deletions)

View changed files

📝 frontend/cypress/e2e/task/date-display.spec.ts (+64 -8)
➕ frontend/src/composables/useTimeFormat.ts (+9 -0)
➕ frontend/src/constants/timeFormat.ts (+6 -0)
📝 frontend/src/helpers/time/formatDate.ts (+21 -12)
📝 frontend/src/i18n/lang/en.json (+5 -0)
📝 frontend/src/modelTypes/IUserSettings.ts (+2 -0)
📝 frontend/src/models/userSettings.ts (+2 -0)
📝 frontend/src/stores/auth.ts (+2 -0)
📝 frontend/src/views/user/settings/General.vue (+29 -2)

📄 Description

Implementation: Add configurable time format (12h/24h) for non-relative dates ✅

Addressed feedback from @kolaente:

  1. ✅ Added configuration to choose between AM/PM (12-hour) or HH:mm (24-hour) time formats
  2. ✅ Removed "HH:mm" placeholder from date display dropdown options
  3. ✅ Fixed 12-hour format to respect user preference regardless of locale
  4. ✅ Added default timeFormat value in all IFrontendSettings initializations

Changes Made

  1. New time format constant (frontend/src/constants/timeFormat.ts):

    • Added TIME_FORMAT with options: HOURS_12 ('12h') and HOURS_24 ('24h')

  2. Updated settings model (frontend/src/modelTypes/IUserSettings.ts):

    • Added timeFormat: TimeFormat to IFrontendSettings interface

  3. Created time format composable (frontend/src/composables/useTimeFormat.ts):

    • Provides reactive access to user's time format preference

  4. Enhanced date formatting (frontend/src/helpers/time/formatDate.ts):

    • Updated formatDisplayDateFormat() to accept optional timeFormat parameter
    • Uses explicit hh:mm A format for 12-hour instead of locale-dependent LT
    • Uses HH:mm for 24-hour format
    • For Intl.DateTimeFormat, sets hour12 option accordingly

  5. Updated settings UI (frontend/src/views/user/settings/General.vue):

    • Added time format selector (visible only when date format is not "relative")
    • Options: "12-hour (AM/PM)" or "24-hour (HH:mm)"
    • Defaults to 12-hour format for backward compatibility

  6. Updated translations (frontend/src/i18n/lang/en.json):

    • Added "Time format" label and options
    • Removed "HH:mm" from date display option labels

  7. Enhanced tests (frontend/cypress/e2e/task/date-display.spec.ts):

    • Updated test expectations to use explicit hh:mm A format for 12-hour
    • Tests verify correct formatting for each time format option

  8. Added default values (frontend/src/models/userSettings.ts, frontend/src/stores/auth.ts):

    • Fixed: Added timeFormat: TIME_FORMAT.HOURS_12 default in UserSettingsModel
    • Fixed: Added timeFormat: TIME_FORMAT.HOURS_12 default in loadSettings()
    • Ensures all IFrontendSettings objects have the required timeFormat property
    • Prevents TypeScript errors and runtime undefined values for new users

Verification

✅ Frontend linter passed: pnpm run lint
✅ Unit tests passed: pnpm run test:unit (706 tests)
✅ Build successful: pnpm run build:dev

Result

Time Format Configuration:

  • 12-hour format: Always shows hh:mm AM/PM regardless of locale
  • 24-hour format: Always shows HH:mm
  • Default value: 12-hour format for all users (new and existing)
  • Type safety: All IFrontendSettings objects now properly initialize timeFormat

Examples:

  • English user with 12-hour: "07-25-2022 12:34 PM"
  • German user with 12-hour: "25-07-2022 12:34 PM" (respects preference, not locale)
  • Any user with 24-hour: "07-25-2022 12:34"

The fix ensures proper TypeScript type checking and prevents undefined values at runtime for users who haven't saved the time format setting yet.

Original prompt

Implementation Plan

You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications.

GOAL

when setting the date display to something other than relative, the time should be shown as well. Integrate into the settings as well.

Process Steps

Step 1: Context Gathering & Initial Analysis

  1. Read all mentioned files immediately and FULLY:

    • Ticket files (e.g., thoughts/allison/tickets/eng_1234.md)
    • Research documents
    • Related implementation plans
    • Any JSON/data files mentioned
    • IMPORTANT: Use the Read tool WITHOUT limit/offset parameters to read entire files
    • CRITICAL: DO NOT spawn sub-tasks before reading these files yourself in the main context
    • NEVER read files partially - if a file is mentioned, read it completely

  2. Spawn initial research tasks to gather context:
    Before asking the user any questions, do your research:

    • Find all files related to the ticket/task
    • Look at the files to understand how the current implementation works

    These agents will:

    • Find relevant source files, configs, and tests
    • Trace data flow and key functions

  3. Read all files identified by research tasks:

    • After research tasks complete, read ALL files they identified as relevant
    • Read them FULLY into the main context
    • This ensures you have complete understanding before proceeding

  4. Analyze and verify understanding:

    • Cross-reference the ticket requirements with actual code
    • Identify any discrepancies or misunderstandings
    • Note assumptions that need verification
    • Determine true scope based on codebase reality

  5. Present informed understanding and focused questions:

    Based on the ticket and my research of the codebase, I understand we need to [accurate summary].

I've found that:
- [Current implementation detail with file:line reference]
- [Relevant pattern or constraint discovered]
- [Potential complexity or edge case identified]

Questions that my research couldn't answer:
- [Specific technical question that requires human judgment]
- [Business logic clarification]
- [Design preference that affects implementation]

    Only ask questions that you genuinely cannot answer through code investigation.

Step 2: Research & Discovery

After getting initial clarifications:

  1. If the user corrects any misunderstanding:

    • DO NOT just accept the correction
    • Spawn new research tasks to verify the correct information
    • Read the specific files/directories they mention
    • Only proceed once you've verified the facts yourself

  2. Create a research todo list use a TODO.md file to track exploration tasks, update as you make progress

  3. Spawn parallel sub-tasks for comprehensive research:

    • Create multiple Task agents to research different aspects concurrently

    Each agent knows how to:

    • Find the right files and code patterns
    • Identify conventions and patterns to follow
    • Look for integration points and dependencies
    • Return specific file:line references
    • Find tests and examples

  4. Wait for ALL sub-tasks to complete before proceeding

  5. Present findings and design options:

    Based on my research, here's what I found:

**Current State:**
- [Key discovery about existing code]
- [Pattern or convention to follow]

**Design Options:**
1. [Option A] - [pros/cons]
2. [Option B] - [pros/cons]

**Open Questions:**
- [Technical uncertainty]
- [Design decision needed]

Which approach aligns best with your vision?

Step 3: Plan Structure Development

Once aligned on approach:

  1. Create initial plan outline:

    Here's my proposed plan structure:

## Overview
[1-2 sentence summary]

## Implementation Phases:
1. [Phase name] - [what it accomplishes]
2. [Phase name] - [what it accomplishes]
3. [Phase name] - [what it accomplishes]
[More phases as needed]

Does this phasing make sense? Should I adjust the order or granularity?

  2. Get feedback on structure before writing details

Step 4: Detailed Plan Writing

After structure approval:

  1. Write the plan to PLAN.md
  2. Use this template structure:
# [Feature/Task Name] Implementation Plan

## Overview

[Brief description of what we're implementing and why]

## Current State Analysis

[What exists now, what's missing, key constraints discovered]

## Desired End State

[A Specification of the desired end state after this plan is complete, and how to verify it]

### Key Discoveries:
- [Important finding with file:line reference]
- [Pattern to follow]
- [Constraint to work within]

## What We're NOT Doing

[Explicitly list out-of-scope items to prevent scope creep]

## Implementation Approach

[High-level strategy ...

</details>



<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---

<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
## 📋 Pull Request Information **Original PR:** https://github.com/go-vikunja/vikunja/pull/1807 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 11/12/2025 **Status:** ✅ Merged **Merged:** 11/13/2025 **Merged by:** [@kolaente](https://github.com/kolaente) **Base:** `main` ← **Head:** `copilot/update-date-display-settings` --- ### 📝 Commits (7) - [`831943f`](https://github.com/go-vikunja/vikunja/commit/831943fd222d0f808622797f6fd01361763e0882) Initial plan - [`3fb0142`](https://github.com/go-vikunja/vikunja/commit/3fb014277c7cd5345d1f919f60e6ee3fa62264a8) feat: add time display to non-relative date formats - [`c98d690`](https://github.com/go-vikunja/vikunja/commit/c98d6906d50014190ac429aea3a0ef00d4294092) feat: add configurable time format (12h/24h) for non-relative dates - [`c7ffafe`](https://github.com/go-vikunja/vikunja/commit/c7ffafe1c3aae2e881718c4af2b3dc267126ce6c) fix: remove HH:mm placeholder from date display options - [`8509f9c`](https://github.com/go-vikunja/vikunja/commit/8509f9c52af50dacd24cf32200da7ee5d24b49eb) fix: use explicit 12-hour format to respect user preference regardless of locale - [`1346769`](https://github.com/go-vikunja/vikunja/commit/1346769bbf9bc41738f2224d7205fccb02b17156) fix: add timeFormat default value in all IFrontendSettings initializations - [`01a953a`](https://github.com/go-vikunja/vikunja/commit/01a953aebaefde94a31540409a80612e566361db) default to 24h ### 📊 Changes **9 files changed** (+140 additions, -22 deletions) <details> <summary>View changed files</summary> 📝 `frontend/cypress/e2e/task/date-display.spec.ts` (+64 -8) ➕ `frontend/src/composables/useTimeFormat.ts` (+9 -0) ➕ `frontend/src/constants/timeFormat.ts` (+6 -0) 📝 `frontend/src/helpers/time/formatDate.ts` (+21 -12) 📝 `frontend/src/i18n/lang/en.json` (+5 -0) 📝 `frontend/src/modelTypes/IUserSettings.ts` (+2 -0) 📝 `frontend/src/models/userSettings.ts` (+2 -0) 📝 `frontend/src/stores/auth.ts` (+2 -0) 📝 `frontend/src/views/user/settings/General.vue` (+29 -2) </details> ### 📄 Description ## Implementation: Add configurable time format (12h/24h) for non-relative dates ✅ **Addressed feedback from @kolaente:** 1. ✅ Added configuration to choose between AM/PM (12-hour) or HH:mm (24-hour) time formats 2. ✅ Removed "HH:mm" placeholder from date display dropdown options 3. ✅ Fixed 12-hour format to respect user preference regardless of locale 4. ✅ Added default timeFormat value in all IFrontendSettings initializations ### Changes Made 1. **New time format constant** (`frontend/src/constants/timeFormat.ts`): - Added `TIME_FORMAT` with options: `HOURS_12` ('12h') and `HOURS_24` ('24h') 2. **Updated settings model** (`frontend/src/modelTypes/IUserSettings.ts`): - Added `timeFormat: TimeFormat` to `IFrontendSettings` interface 3. **Created time format composable** (`frontend/src/composables/useTimeFormat.ts`): - Provides reactive access to user's time format preference 4. **Enhanced date formatting** (`frontend/src/helpers/time/formatDate.ts`): - Updated `formatDisplayDateFormat()` to accept optional `timeFormat` parameter - Uses explicit `hh:mm A` format for 12-hour instead of locale-dependent `LT` - Uses `HH:mm` for 24-hour format - For Intl.DateTimeFormat, sets `hour12` option accordingly 5. **Updated settings UI** (`frontend/src/views/user/settings/General.vue`): - Added time format selector (visible only when date format is not "relative") - Options: "12-hour (AM/PM)" or "24-hour (HH:mm)" - Defaults to 12-hour format for backward compatibility 6. **Updated translations** (`frontend/src/i18n/lang/en.json`): - Added "Time format" label and options - Removed "HH:mm" from date display option labels 7. **Enhanced tests** (`frontend/cypress/e2e/task/date-display.spec.ts`): - Updated test expectations to use explicit `hh:mm A` format for 12-hour - Tests verify correct formatting for each time format option 8. **Added default values** (`frontend/src/models/userSettings.ts`, `frontend/src/stores/auth.ts`): - **Fixed**: Added `timeFormat: TIME_FORMAT.HOURS_12` default in `UserSettingsModel` - **Fixed**: Added `timeFormat: TIME_FORMAT.HOURS_12` default in `loadSettings()` - Ensures all IFrontendSettings objects have the required timeFormat property - Prevents TypeScript errors and runtime undefined values for new users ### Verification ✅ Frontend linter passed: `pnpm run lint` ✅ Unit tests passed: `pnpm run test:unit` (706 tests) ✅ Build successful: `pnpm run build:dev` ### Result **Time Format Configuration:** - **12-hour format**: Always shows `hh:mm AM/PM` regardless of locale - **24-hour format**: Always shows `HH:mm` - **Default value**: 12-hour format for all users (new and existing) - **Type safety**: All IFrontendSettings objects now properly initialize timeFormat **Examples:** - English user with 12-hour: "07-25-2022 12:34 PM" - German user with 12-hour: "25-07-2022 12:34 PM" (respects preference, not locale) - Any user with 24-hour: "07-25-2022 12:34" The fix ensures proper TypeScript type checking and prevents undefined values at runtime for users who haven't saved the time format setting yet. <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> # Implementation Plan You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications. ## GOAL when setting the date display to something other than relative, the time should be shown as well. Integrate into the settings as well. ## Process Steps ### Step 1: Context Gathering & Initial Analysis 1. **Read all mentioned files immediately and FULLY**: - Ticket files (e.g., `thoughts/allison/tickets/eng_1234.md`) - Research documents - Related implementation plans - Any JSON/data files mentioned - **IMPORTANT**: Use the Read tool WITHOUT limit/offset parameters to read entire files - **CRITICAL**: DO NOT spawn sub-tasks before reading these files yourself in the main context - **NEVER** read files partially - if a file is mentioned, read it completely 2. **Spawn initial research tasks to gather context**: Before asking the user any questions, do your research: - Find all files related to the ticket/task - Look at the files to understand how the current implementation works These agents will: - Find relevant source files, configs, and tests - Trace data flow and key functions 3. **Read all files identified by research tasks**: - After research tasks complete, read ALL files they identified as relevant - Read them FULLY into the main context - This ensures you have complete understanding before proceeding 4. **Analyze and verify understanding**: - Cross-reference the ticket requirements with actual code - Identify any discrepancies or misunderstandings - Note assumptions that need verification - Determine true scope based on codebase reality 5. **Present informed understanding and focused questions**: ``` Based on the ticket and my research of the codebase, I understand we need to [accurate summary]. I've found that: - [Current implementation detail with file:line reference] - [Relevant pattern or constraint discovered] - [Potential complexity or edge case identified] Questions that my research couldn't answer: - [Specific technical question that requires human judgment] - [Business logic clarification] - [Design preference that affects implementation] ``` Only ask questions that you genuinely cannot answer through code investigation. ### Step 2: Research & Discovery After getting initial clarifications: 1. **If the user corrects any misunderstanding**: - DO NOT just accept the correction - Spawn new research tasks to verify the correct information - Read the specific files/directories they mention - Only proceed once you've verified the facts yourself 2. **Create a research todo list** use a TODO.md file to track exploration tasks, update as you make progress 3. **Spawn parallel sub-tasks for comprehensive research**: - Create multiple Task agents to research different aspects concurrently Each agent knows how to: - Find the right files and code patterns - Identify conventions and patterns to follow - Look for integration points and dependencies - Return specific file:line references - Find tests and examples 3. **Wait for ALL sub-tasks to complete** before proceeding 4. **Present findings and design options**: ``` Based on my research, here's what I found: **Current State:** - [Key discovery about existing code] - [Pattern or convention to follow] **Design Options:** 1. [Option A] - [pros/cons] 2. [Option B] - [pros/cons] **Open Questions:** - [Technical uncertainty] - [Design decision needed] Which approach aligns best with your vision? ``` ### Step 3: Plan Structure Development Once aligned on approach: 1. **Create initial plan outline**: ``` Here's my proposed plan structure: ## Overview [1-2 sentence summary] ## Implementation Phases: 1. [Phase name] - [what it accomplishes] 2. [Phase name] - [what it accomplishes] 3. [Phase name] - [what it accomplishes] [More phases as needed] Does this phasing make sense? Should I adjust the order or granularity? ``` 2. **Get feedback on structure** before writing details ### Step 4: Detailed Plan Writing After structure approval: 1. **Write the plan** to `PLAN.md` 2. **Use this template structure**: ```markdown # [Feature/Task Name] Implementation Plan ## Overview [Brief description of what we're implementing and why] ## Current State Analysis [What exists now, what's missing, key constraints discovered] ## Desired End State [A Specification of the desired end state after this plan is complete, and how to verify it] ### Key Discoveries: - [Important finding with file:line reference] - [Pattern to follow] - [Constraint to work within] ## What We're NOT Doing [Explicitly list out-of-scope items to prevent scope creep] ## Implementation Approach [High-level strategy ... </details> <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-16 13:31:34 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#5238
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?