What problem does it solve?
Bare calls like LocalDate.now(), new Date(), or time.Now() depend on the JVM or OS default timezone, so the same code produces different results on a developer machine (Asia/Shanghai) and a production container (UTC), causing week/month/day boundary statistics to drift by hours.
Core Features & Use Cases
- Bare .now() Detection: Provides grep-based sniffing commands to find LocalDate.now(), LocalDateTime.now(), new Date(), Date.now(), and time.Now() across Java, Go, Python, and TypeScript codebases.
- Boundary Calculation Rules: Shows correct patterns for computing week start, month start, and day start with an explicit business timezone constant (BIZ_ZONE).
- Database Timezone Alignment: Covers JDBC serverTimezone settings, DATETIME vs TIMESTAMP column strategy, and Docker TZ pinning to keep the application and database layers consistent.
- Use Case: A daily order statistics query returns no rows after midnight deployment because the server runs UTC while the database stores Asia/Shanghai times; this Skill walks through fixing the query boundary, JDBC URL, and container timezone.
Quick Start
Review my Java service for unsafe LocalDate.now() and week-start calculations and rewrite them to use an explicit Asia/Shanghai business timezone.