<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Zoneddatetime on Devops Monk</title><link>https://blog.devops-monk.com/tags/zoneddatetime/</link><description>Recent content in Zoneddatetime on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 04 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.devops-monk.com/tags/zoneddatetime/index.xml" rel="self" type="application/rss+xml"/><item><title>Date and Time API (JSR-310): LocalDate, ZonedDateTime, Duration, Period</title><link>https://blog.devops-monk.com/tutorials/java8/date-time-api/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>https://blog.devops-monk.com/tutorials/java8/date-time-api/</guid><description>Why java.util.Date Had to Go If you have ever tracked down a bug caused by a SimpleDateFormat shared across threads, or spent an afternoon understanding why a Calendar.get(Calendar.MONTH) returns 0 for January, you will appreciate why JSR-310 was one of the most eagerly anticipated Java 8 features. The new java.time API is not a patch on the old API — it is a complete redesign that makes an entire class of date and time bugs impossible by construction.</description></item></channel></rss>