Refactor Plan: Extracting Shared Date Utility to Internal Monorepo Package

Assume the role of a senior staff engineer with deep expertise in large-scale refactoring, monorepo management, and internal package development. Your focus is on incremental, safe-by-default migrations.

Context:
Our organization operates a monorepo containing multiple services and applications. We have identified a common date utility, currently duplicated or inconsistently implemented across several projects. The goal is to extract this utility into a dedicated, versioned internal package to improve consistency, maintainability, and reduce technical debt. We are currently using `{{monorepo_tooling_details}}` for package management and dependency resolution. The utility's current implementation details are `{{current_date_utility_details}}`. A preliminary list of directly `{{dependent_projects_list}}` that use this utility has been compiled.

Task:
Develop a comprehensive refactoring plan to safely extract the identified date utility into a new, versioned internal package. This plan must cover all critical aspects from initial analysis to post-migration validation, prioritizing stability and minimal impact on ongoing development.

Constraints:
1.  **Safety First**: The migration must not introduce regressions or break existing functionality in dependent projects.
2.  **Incremental Approach**: Design the plan to allow for phased adoption or a clear cutover strategy, minimizing large, risky changes.
3.  **Versioning**: The new internal package must adhere to semantic versioning (e.g., SemVer) principles from its inception.
4.  **Monorepo Compatibility**: The plan must integrate smoothly with our existing `{{monorepo_tooling_details}}` for publishing, consuming, and managing dependencies.
5.  **Documentation**: Key decisions and steps must be documented for future reference and onboarding.
6.  **Rollback Strategy**: A clear, tested rollback procedure must be defined for each major step.

Output:
Provide the refactoring plan structured into the following sections:

### Refactor Plan: Date Utility Extraction

**1. Current State Analysis**
    *   Brief description of the current date utility's implementation (as provided in `{{current_date_utility_details}}`).
    *   Identification of all direct and indirect `{{dependent_projects_list}}` that consume this utility.
    *   Analysis of current usage patterns and potential points of friction during extraction.

**2. Target Architecture**
    *   Proposed name and structure for the new internal package (e.g., `@org/date-utils`).
    *   Definition of the package's public API (exported functions, types).
    *   Strategy for versioning the new package (e.g., initial `1.0.0` release).
    *   How the new package will integrate with `{{monorepo_tooling_details}}`.

**3. Step-by-Step Migration Plan**
    *   **Phase 1: Package Creation and Initial Release**
        *   Steps to create the new package boilerplate within the monorepo.
        *   Migration of the core date utility logic into the new package.
        *   Publishing the initial version of the package.
    *   **Phase 2: Dependent Project Updates**
        *   Strategy for updating `{{dependent_projects_list}}` to consume the new package.
        *   Approach for deprecating the old utility (if applicable) or replacing direct implementations.
        *   Consideration for staggered adoption or a flag-based rollout if necessary.
    *   **Phase 3: Cleanup and Deprecation**
        *   Steps to remove old utility implementations from `{{dependent_projects_list}}` once all consumers have migrated.
        *   Final removal of deprecated code paths.

**4. Test Strategy**
    *   Unit testing for the new internal package.
    *   Integration testing for `{{dependent_projects_list}}` to ensure functionality post-migration.
    *   End-to-end testing considerations for critical user flows.
    *   Performance testing if the utility is performance-critical.

**5. Rollback Plan**
    *   Detailed steps to revert changes in case of critical issues at each phase (package creation, dependent updates).
    *   Instructions for reverting package versions or restoring previous codebases in `{{dependent_projects_list}}`.
    *   Communication plan for stakeholders during a rollback event.