halloween-test/.claude/time-recording-policy.md

Time Recording Policy

Critical Rule: No Fabricated Timestamps

All AI agents and team members must follow this policy strictly.

Policy Statement

1. Never invent, fabricate, or hallucinate dates and times
2. Use actual system time or explicitly mark as TBD
3. Record all timestamps in dual timezone format

Required Format

Dual Timezone Recording

Every timestamp must be recorded in BOTH timezones:

Created: 2025-10-04 08:50:35 UTC
Created: 2025-10-04 16:50:35 GMT+8

Format Specification

• UTC: Coordinated Universal Time (reference timezone)
• GMT+8: Asia/Shanghai timezone (local timezone)
• Format: YYYY-MM-DD HH:MM:SS [TIMEZONE]

When to Use TBD

If the actual date/time is not yet determined, use:

Event Date: TBD
Event Time: TBD
Deadline: To be determined

Never guess or estimate dates for future events.

Examples

✅ Correct Usage

Document Creation:

## Document Information
Created: 2025-10-04 08:50:35 UTC
Created: 2025-10-04 16:50:35 GMT+8
Last Modified: 2025-10-04 08:50:35 UTC
Last Modified: 2025-10-04 16:50:35 GMT+8

Event Planning:

## Halloween Event
Event Date: TBD (awaiting confirmation from McDonald's IT)
Event Time: TBD
RSVP Deadline: TBD

Git Commits:

# Commit messages automatically include accurate timestamps
git commit -m "docs: add time recording policy"
# Git will use system time automatically

Meeting Notes:

## Meeting Notes
Date: 2025-10-04 08:50:35 UTC / 2025-10-04 16:50:35 GMT+8
Attendees: [List]
Next Meeting: TBD

❌ Incorrect Usage

DO NOT do this:

# Wrong - fabricated future date
Event Date: October 31, 2024
Event Time: 6:00 PM - 10:00 PM

# Wrong - guessed date
Deadline: Next Friday

# Wrong - relative time without reference
Updated: Yesterday

# Wrong - single timezone only
Created: 2025-10-04 16:50:35

Implementation Guidelines

For All Agents

1. When creating documents:

   • Add creation timestamp in dual format
   • Use actual system time

2. When recording events:

   • Use TBD for unconfirmed dates
   • Update with actual dates once confirmed

3. When updating documents:

   • Add "Last Modified" timestamp
   • Keep original creation timestamp

4. When planning:

   • Use "Target Date: TBD" for estimates
   • Never commit to specific dates without authorization

For DevOps Engineer

Special responsibilities:

• Verify all documentation follows time policy
• Audit commits for accurate timestamps
• Ensure CI/CD logs use correct timezone format
• Monitor for policy violations

For Product Manager

When creating specifications:

• Mark all deadlines as TBD until confirmed
• Document when dates are confirmed
• Update changelog with actual decision dates

For Scrum Master

When planning sprints:

• Use actual sprint start/end dates
• Mark future sprint dates as TBD
• Record retrospective dates accurately

Getting Current Time

Command Line (Unix/Linux/macOS)

# UTC time
TZ=UTC date '+%Y-%m-%d %H:%M:%S %Z'

# GMT+8 time
TZ=Asia/Shanghai date '+%Y-%m-%d %H:%M:%S %Z'

# Both at once
echo "UTC: $(TZ=UTC date '+%Y-%m-%d %H:%M:%S %Z')" && \
echo "GMT+8: $(TZ=Asia/Shanghai date '+%Y-%m-%d %H:%M:%S %Z')"

In Documentation

<!-- Use actual system time when creating -->
Created: [Run: date -u '+%Y-%m-%d %H:%M:%S UTC']
Created: [Run: TZ=Asia/Shanghai date '+%Y-%m-%d %H:%M:%S GMT+8']

Verification Checklist

Before committing any document:

• All timestamps use dual timezone format
• No fabricated or guessed dates
• Future events marked as TBD
• Creation date reflects actual creation time
• Last modified date is current (if updated)
• Timezone abbreviations are correct (UTC/GMT+8)

Rationale

Why this policy exists:

1. Accuracy: Prevents confusion from incorrect timestamps
2. Accountability: Clear record of when decisions were made
3. Global Collaboration: Dual timezone supports distributed teams
4. Audit Trail: Accurate history for compliance and review
5. Trust: Demonstrates professional documentation practices

Policy Violations

If you discover fabricated timestamps:

1. Immediate Action: Flag the issue
2. Correction: Update with TBD or actual time
3. Documentation: Note the correction in commit message
4. Prevention: Review why the error occurred

Questions?

Contact the DevOps engineer or project lead for clarification.

---

Policy Version: 1.0
Effective Date: 2025-10-04 08:50:35 UTC / 2025-10-04 16:50:35 GMT+8
Last Updated: 2025-10-04 08:50:35 UTC / 2025-10-04 16:50:35 GMT+8
Owner: DevOps Engineer
Approved By: Project Team