Timestamp de fin de año

End-of-year boundary

For most database filters, the clean boundary is the start of next year at 00:00:00 UTC. Use it as an exclusive upper bound: created_at >= yearStart and created_at < nextYearStart.

Why exclusive upper bounds are safer

Exclusive upper bounds avoid off-by-one-second and millisecond precision bugs. They also work cleanly across databases that store fractional seconds.

Using the year-end boundary

The safest end-of-year timestamp is the first instant of the next year, used as an exclusive upper bound. It represents the point where the current year stops without depending on whether your storage keeps seconds, milliseconds, microseconds, or nanoseconds. That makes the same filter portable across logs, APIs, and SQL databases.

• Use created_at < nextYearStart instead of created_at <= lastSecondOfYear
• Use the millisecond value for JavaScript and frontend chart ranges
• Use the second value for Unix tools and most backend timestamp columns
• Pair the value with yearStart when checking complete annual ranges

Verifying the year-end value

Convert the copied value back to UTC and confirm it is January 1 at 00:00:00 for the next year. Although people call it year end, this boundary is intentionally the first instant after the year, which keeps database filters clean at second, millisecond, and microsecond precision. It also avoids deciding whether the last stored record uses 23:59:59, 23:59:59.999, or a finer fractional value.