If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/JodaOrg/joda-time shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 19 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 58% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live JodaOrg/joda-time repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JodaOrg/joda-time.

What it runs against: a local clone of JodaOrg/joda-time — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in JodaOrg/joda-time | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 40 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of JodaOrg/joda-time. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/JodaOrg/joda-time.git
#   cd joda-time
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of JodaOrg/joda-time and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JodaOrg/joda-time(\\.git)?\\b" \\
  && ok "origin remote is JodaOrg/joda-time" \\
  || miss "origin remote is not JodaOrg/joda-time (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/main/java/org/joda/time/DateTime.java" \\
  && ok "src/main/java/org/joda/time/DateTime.java" \\
  || miss "missing critical file: src/main/java/org/joda/time/DateTime.java"
test -f "src/main/java/org/joda/time/Chronology.java" \\
  && ok "src/main/java/org/joda/time/Chronology.java" \\
  || miss "missing critical file: src/main/java/org/joda/time/Chronology.java"
test -f "src/main/java/org/joda/time/DateTimeZone.java" \\
  && ok "src/main/java/org/joda/time/DateTimeZone.java" \\
  || miss "missing critical file: src/main/java/org/joda/time/DateTimeZone.java"
test -f "src/main/java/org/joda/time/chrono/BaseChronology.java" \\
  && ok "src/main/java/org/joda/time/chrono/BaseChronology.java" \\
  || miss "missing critical file: src/main/java/org/joda/time/chrono/BaseChronology.java"
test -f "src/main/java/org/joda/time/base/BaseDateTime.java" \\
  && ok "src/main/java/org/joda/time/base/BaseDateTime.java" \\
  || miss "missing critical file: src/main/java/org/joda/time/base/BaseDateTime.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 40 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~10d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/JodaOrg/joda-time"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Joda-Time is a mature Java library providing a replacement for the legacy java.util.Date and java.util.Calendar classes, offering immutable date/time objects and support for multiple calendar systems (ISO8601, Gregorian, Julian, Buddhist, Coptic, Ethiopic, Islamic). It provides timezone handling, duration calculations, formatting/parsing via a fluent API and is the de facto standard for Java date/time work prior to Java 8's java.time (JSR-310). Monolithic JAR structure: src/main/java/org/joda/time/ contains core classes (DateTime.java, DateTimeZone.java, Chronology.java, Duration.java, etc.), organized by responsibility; src/example/ contains runnable examples (AgeCalculator.java, DateTimePerformance.java); src/main/checkstyle/ enforces code style; src/changes/ tracks release notes via Maven changes plugin.

Java developers working on legacy applications (pre-Java 8) or Android projects targeting API level 25 or lower who need robust, intuitive date/time handling without the pitfalls of java.util.Date; maintainers of existing Joda-Time codebases.

Production-ready and stable at v2.14.2 (released recently, visible in pom.xml). Codebase is 20+ years old (inceptionYear: 2002), well-tested, with active GitHub workflows for CI/build/tzdb updates. However, project is officially in maintenance-only mode—new feature development has ceased in favor of java.time migration, with primary activity limited to timezone data updates.

Low adoption risk for existing users (stable API, no breaking changes expected), but strategic risk: Joda-Time is deprecated in favor of java.time since Java 8; new projects should use java.time or ThreeTenABP (for Android <26). Single primary maintainer (jodastephen) visible in pom.xml, though community contributions are tracked. No major dependency risks noted—library is largely self-contained.

Active GitHub workflows (build.yml, tzdbupdate.yml, cifuzz.yml, release.yml) indicate CI/CD automation and timezone database maintenance. No active feature development visible; primary focus is stability and timezone data sync. CII Best Practices badge suggests security posture is maintained.

git clone https://github.com/JodaOrg/joda-time.git
cd joda-time
mvn clean install
mvn test

Daily commands:

mvn test                    # Run test suite
mvn clean package          # Build JAR to target/joda-time-2.14.2.jar
cd src/example && javac -cp ../../target/joda-time-2.14.2.jar org/joda/example/time/Examples.java
java -cp ../../target/joda-time-2.14.2.jar org.joda.example.time.Examples  # Run example

• src/main/java/org/joda/time/DateTime.java — Primary mutable instant class that combines date and time; foundational entry point for most datetime operations.
• src/main/java/org/joda/time/Chronology.java — Abstract interface defining calendar system behavior; essential for understanding how different calendars (ISO, Gregorian, Islamic, etc.) are plugged in.
• src/main/java/org/joda/time/DateTimeZone.java — Timezone handling abstraction; critical for accurate instant-to-local conversions and DST management.
• src/main/java/org/joda/time/chrono/BaseChronology.java — Base implementation for all chronology systems; houses shared logic for calendar calculations and field factories.
• src/main/java/org/joda/time/base/BaseDateTime.java — Core base class for all datetime types (mutable and immutable); establishes read/write interface and field access patterns.
• src/main/java/org/joda/time/LocalDate.java — Immutable date-only type without timezone; frequently used for date-only logic and serves as reference for local datetime design.
• pom.xml — Maven build configuration defining Java version targets, dependencies, and release process; required for building and understanding version compatibility.

Add a new Calendar System (e.g., Mayan, Hebrew)

1. Create a new chronology class extending BaseChronology or BasicChronology in src/main/java/org/joda/time/chrono/ (src/main/java/org/joda/time/chrono/YourCalendarChronology.java)
2. Override assemble() to wire field implementations (year, month, day, etc.) using AssembledChronology helper (src/main/java/org/joda/time/chrono/YourCalendarChronology.java)
3. Implement getDateTimeMillis(y,m,d,h,m,s,ms) to convert calendar units to milliseconds since epoch (src/main/java/org/joda/time/chrono/YourCalendarChronology.java)
4. Create custom DateTimeField subclasses if needed (e.g., YourMonthOfYearField) in the same chrono package (src/main/java/org/joda/time/chrono/YourMonthOfYearDateTimeField.java)
5. Register the new chronology in a factory method or getInstance() static that caches instances (src/main/java/org/joda/time/chrono/YourCalendarChronology.java)
6. Update DateTime, LocalDate, and other core types to accept your chronology in their constructor or getInstance() methods (src/main/java/org/joda/time/DateTime.java)

Add a new DateTimeField Type (e.g., quarter-of-year, day-of-week-in-month)

1. Add a new enum constant to DateTimeFieldType (src/main/java/org/joda/time/DateTimeFieldType.java)
2. Create a custom DateTimeField subclass in the appropriate chronology package (e.g., BasicQuarterOfYearDateTimeField) (src/main/java/org/joda/time/chrono/BasicQuarterOfYearDateTimeField.java)
3. Implement getMinimumValue(), getMaximumValue(), and add() to support the new field's arithmetic (src/main/java/org/joda/time/chrono/BasicQuarterOfYearDateTimeField.java)
4. Wire the field into BaseChronology.assemble() or your custom chronology's field map (src/main/java/org/joda/time/chrono/BaseChronology.java)
5. Update DateTimeUtils or convenience methods to expose the field from DateTime/LocalDate objects if needed (src/main/java/org/joda/time/DateTime.java)

Add a new Period Type (e.g., Quarters, Decades)

1. Create a new class extending BaseSingleFieldPeriod for single-field periods, or use Period directly for multi-field (src/main/java/org/joda/time/Quarters.java)
2. Define parse() and of()

Java 5 target: pom.xml notes 'Build does not work on Java 9 or later as Java 5 is not a valid target'—compile with Java 8 or check Maven version compatibility. No external timezone data downloads needed at runtime (TZDB is embedded in JAR). Daylight saving time transitions can be subtle; test date arithmetic near DST boundaries. Month constants are 1-indexed in public API (February = 2) despite internal 0-indexing—easy source of off-by-one errors.

• Immutable value objects — Joda-Time's entire API (DateTime, LocalDate, Duration) is immutable—operations return new objects; this prevents entire class of bugs (accidental mutation) and enables safe multi-threaded use without synchronization, which is non-obvious to developers coming from java.util.Calendar.
• Chronology pattern — Joda-Time's Chronology abstraction allows pluggable calendar systems (ISO8601, Gregorian, Buddhist, Islamic) rather than hardcoding one; understanding this pattern is key to extending the library or understanding why date arithmetic behaves differently across calendars.
• Temporal field pattern — DateTimeField and DurationField encapsulate get/add/round operations for each temporal unit (day, month, year); this design enables fluent, composable arithmetic (e.g., .plusDays(3).withHourOfDay(0)) without combinatorial explosion of methods.
• Timezone-aware instant vs local datetime — Joda-Time distinguishes DateTime (instant with timezone) from LocalDate/LocalTime (civil datetime without timezone), a subtle but critical difference for cross-timezone calculations; many bugs arise from confusing these two concepts.
• Period vs Duration — Period represents human calendar units (days/months/years) and accounts for DST/variable-length months, while Duration is absolute elapsed time in milliseconds; using the wrong one causes DST-related bugs or unexpected month-end behavior.
• Factory method pattern — Joda-Time uses static factories (DateTime.now(), LocalDate.parse(), Days.daysBetween()) instead of constructors; this enables lazy initialization, caching, and version-safe object creation—important for understanding API stability and testing.
• IANA timezone database (TZDB) embedding — Joda-Time embeds and auto-syncs the official IANA timezone database (via tzdbupdate.yml workflow) to handle DST rules, historical timezone changes, and leap seconds; understanding this is critical for timezone-sensitive applications.

• threeten/threetenbp — Backport of java.time (JSR-310) to Java 6/7; the recommended migration target for Joda-Time users on Java 8+
• JakeWharton/ThreeTenABP — Android-compatible backport of java.time for API levels <26; the endorsed solution for Joda-Time users on legacy Android
• kiminput/time4j — Alternative Java date/time library with broader calendar system support and more flexible temporal arithmetic (evolving where Joda-Time is maintenance-only)
• JodaOrg/joda-money — Companion library from same maintainer for currency/money arithmetic; often paired with Joda-Time for financial date calculations
• eggert/tz — Official timezone database (IANA TZDB) upstream; Joda-Time embeds this data and syncs via tzdbupdate.yml workflow

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for DateTimeZone timezone transitions and edge cases

The DateTimeZone.java class is fundamental to Joda-Time's functionality, but given the project's active maintenance of timezone data (evidenced by .github/workflows/tzdbupdate.yml), there's likely insufficient test coverage for DST transitions, leap seconds, and historical timezone changes. Contributors could add integration tests that validate timezone behavior across major transition points, especially around the tzdb updates that the repo actively maintains.

• [ ] Create src/test/java/org/joda/time/tz/DateTimeZoneTransitionTests.java for DST edge cases
• [ ] Add test cases for historical timezone transitions (e.g., pre/post 2000 changes)
• [ ] Test DateTimeZone against recent TZDB updates to catch regressions from .github/workflows/tzdbupdate.yml
• [ ] Verify behavior during DST switchovers, leap second handling, and timezone offset changes

Add security vulnerability scanning GitHub Action for dependencies

The repo has .github/workflows/build.yml and other CI workflows, but there's no dedicated dependency vulnerability scanning. Given Joda-Time's widespread use as a legacy date/time library for Java applications, adding OWASP Dependency-Check or similar scanning would help catch transitive dependency vulnerabilities. This aligns with the SECURITY.md file but lacks automated checks.

• [ ] Create .github/workflows/security-scan.yml with OWASP Dependency-Check
• [ ] Configure to run on schedule (weekly) and on pull_request events
• [ ] Add suppression rules in .github or src/main for known false positives
• [ ] Reference vulnerability scanning results in SECURITY.md with remediation steps

Add unit tests for LocalDate, LocalTime, and LocalDateTime parsing edge cases

LocalDate.java, LocalTime.java, and LocalDateTime.java are core immutable types in Joda-Time's API. The example code in README.md shows usage, but contributions could add comprehensive test suites for parsing malformed input, boundary conditions (year 0, year 9999, leap years), and serialization/deserialization edge cases. This directly strengthens API robustness for migration use cases mentioned in the README.

• [ ] Create src/test/java/org/joda/time/LocalDateParsingTests.java for parse edge cases (invalid dates, DST transitions)
• [ ] Create src/test/java/org/joda/time/LocalTimeParsingTests.java for boundary times (23:59:59.999, midnight edge cases)
• [ ] Create src/test/java/org/joda/time/LocalDateTimeSerializationTests.java for serialization round-trip validation
• [ ] Add tests for known problematic dates (Feb 29 leap year handling, year boundaries)

• Add comprehensive JavaDoc examples to DateTimeField.java and DurationField.java showing practical use cases for field arithmetic (e.g., 'get the 3rd Thursday of next month')—currently sparse on usage patterns.
• Expand src/example/org/joda/example/time/Examples.java with runnable examples for timezone DST transitions, Period vs Duration confusion, and Chronology system switching (Buddhist, Islamic calendars)—helps new users avoid common pitfalls.
• Write integration test suite comparing java.time equivalents to Joda-Time operations to document migration path for users upgrading to Java 8+; place in src/test/java/org/joda/time/migrate/

Joda-Time demonstrates reasonable security practices overall with proper licensing, GitHub-based issue tracking, and infrastructure monitoring. However, the project's maintenance status is limited to timezone updates only, and the legacy Java 5 target configuration is concerning from a security perspective. The primary risk is not in the codebase itself but in its outdated build configuration and limited active maintenance. The project appropriately redirects users to java.time for new development. No hardcoded secrets, injection vulnerabilities, or critical misconfigurations were identified in the provided file structure.

• Medium · Outdated Build Target Configuration — pom.xml. The pom.xml contains a comment stating 'Build does not work on Java 9 or later as Java 5 is not a valid target'. This indicates the project is configured to target Java 5, which is extremely outdated (released in 2004) and contains numerous security vulnerabilities. Modern Java versions include significant security improvements. Fix: Update the project to target a modern Java LTS version (Java 11, 17, or 21). Update Maven compiler plugin configuration with appropriate source and target versions. This will enable modern security features and patched vulnerabilities.
• Low · Incomplete Developer Information — pom.xml (developer section). The pom.xml contains a developer entry with an empty email field for Brian S O'Neill. While not a direct security risk, incomplete metadata can impact project maintenance and communication. Fix: Complete the developer information with valid contact details or remove empty fields. This improves project transparency and maintainability.
• Low · Project in Maintenance Mode Only — README.md. The README explicitly states 'Joda-time is no longer in active development except to keep timezone data up to date.' This means the project is not receiving active security updates for general vulnerabilities, only timezone data maintenance. Fix: For new projects, migrate to java.time (JSR-310) as recommended. For existing projects using Joda-Time, monitor timezone data updates and consider migration plans. Users should be aware of the limited maintenance scope.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.