What problem does it solve?
Server code that calls bare LocalDate.now(), new Date(), or time.Now() silently depends on the JVM or container default timezone, so the same code produces different "today" or "week start" values in development (Asia/Shanghai) versus production (UTC), causing statistics and reports to shift by 8 hours.
Core Features & Use Cases
- Bare now() Detection: Provides grep-based sniffing commands to find unqualified
LocalDate.now(), new Date(), time.Now(), and Date.now() calls across Java, Go, Python, and TypeScript codebases.
- Boundary Calculation Rules: Defines correct patterns for computing week, month, and day start points with an explicit business timezone constant like
BIZ_ZONE.
- Database & Deployment Alignment: Covers JDBC
serverTimezone configuration, MySQL DATETIME vs TIMESTAMP strategy selection, and Docker TZ pinning to keep application, database, and infrastructure layers consistent.
- Use Case: A daily order report misses rows after deployment to a UTC-based Docker host. Use this Skill to audit the codebase for bare
.now() calls, fix the week-start calculation with an explicit zone, and align the JDBC connection string.
Quick Start
Ask the AI to review my service-layer code for timezone safety issues and fix any bare now() calls using a unified business timezone constant.