Java中Calendar类常用方法解析-java教程-PHP中文网

Java中Calendar类是处理日期时间的核心工具，通过getInstance()获取实例，set()/get()设置和获取字段，add()/roll()增减时间，getTime()/setTime()与Date转换，before()/after()/compareTo()比较时间。其与Date的关系为：Date表示时间点，Calendar是操作器，常见误区包括误用Date的废弃方法和Calendar的可变性导致的副作用。尽管Java 8推荐使用java.time（因不可变、线程安全、API直观等优势），但Calendar仍在遗留系统、旧API交互及Java 8以下版本中具有不可替代性。处理时区和夏令时时需注意：Calendar默认使用JVM时区，可通过setTimeZone()指定；能自动处理夏令时跳变，但“缺失”或“重复”时间可能引发问题，且依赖JVM时区数据库的更新。因此，在需要兼容旧环境或维护遗留代码时，掌握Calendar仍至关重要。

java中calendar类常用方法解析

Java中的

Calendar

登录后复制

类，在我看来，是处理日期和时间操作的一个核心工具，尤其是在

java.time

登录后复制

包出现之前，它几乎是所有复杂日期计算的基石。理解其常用方法，意味着你掌握了在Java中对时间进行增减、设置、获取以及比较的基础能力，尽管它有一些让人感到困惑的地方，但其核心功能依然强大且不可或缺。

解决方案

在使用

Calendar

登录后复制

类时，我们通常会通过

getInstance()

登录后复制

方法获取一个代表当前时间的

Calendar

登录后复制

实例，然后利用一系列方法对其进行操作。

getInstance()

登录后复制

：获取Calendar实例 这是我们开始一切操作的起点。它会返回一个基于当前时间、默认时区和默认语言环境的

Calendar

登录后复制

对象。

import java.util.Calendar;

Calendar now = Calendar.getInstance();
System.out.println("当前时间: " + now.getTime());

登录后复制

set()

登录后复制

：设置日期和时间字段

set()

登录后复制

方法非常灵活，可以设置年、月、日、小时、分钟、秒等各种字段。值得注意的是，月份是从0开始计数的（0代表1月，11代表12月），这常常是我在编码时需要特别留心的地方。

Calendar specificDate = Calendar.getInstance();
specificDate.set(2023, Calendar.DECEMBER, 25, 10, 30, 0); // 设置2023年12月25日10:30:00
System.out.println("特定日期: " + specificDate.getTime());

// 也可以单独设置某个字段
specificDate.set(Calendar.YEAR, 2024);
System.out.println("年份修改后: " + specificDate.getTime());

登录后复制

get()

登录后复制

：获取日期和时间字段 与

set()

登录后复制

相对应，

get()

登录后复制

方法用于获取指定字段的值。你需要传入

Calendar

登录后复制

类中定义的常量，比如

Calendar.YEAR

登录后复制

、

Calendar.MONTH

登录后复制

等。

int year = now.get(Calendar.YEAR);
int month = now.get(Calendar.MONTH) + 1; // 月份需要加1
int day = now.get(Calendar.DAY_OF_MONTH);
System.out.println("年: " + year + ", 月: " + month + ", 日: " + day);

登录后复制

add()

登录后复制

：增加或减少时间

add()

登录后复制

方法是我最常用也觉得最方便的方法之一，它允许我们对某个时间字段进行增减操作，并且会自动处理日期溢出（例如，给月份加12会自动增加年份）。这在计算未来或过去的日期时非常实用。

立即学习“Java免费学习笔记（深入）”；

now.add(Calendar.DAY_OF_MONTH, 7); // 增加7天
System.out.println("7天后: " + now.getTime());

now.add(Calendar.HOUR_OF_DAY, -3); // 减少3小时
System.out.println("3小时前: " + now.getTime());

登录后复制

roll()

登录后复制

：滚动时间字段

roll()

登录后复制

方法与

add()

登录后复制

相似，但有一个关键区别：它在对某个字段进行增减时，不会影响比它大的字段。比如，对月份进行滚动，年份不会改变。这在某些特定场景下很有用，但用起来也容易混淆，需要特别注意。

Calendar tempCalendar = Calendar.getInstance();
tempCalendar.set(2023, Calendar.DECEMBER, 31);
System.out.println("原始日期: " + tempCalendar.getTime()); // 2023年12月31日

tempCalendar.roll(Calendar.MONTH, 1); // 滚动月份，年份不变
System.out.println("滚动月份后: " + tempCalendar.getTime()); // 2023年1月31日 (因为从12月滚动1个月变成了1月)

登录后复制

getTime()

登录后复制

：将Calendar转换为Date对象

Calendar

登录后复制

对象本身并不直接代表一个时间点，它是一个抽象的概念。要获取一个具体的

java.util.Date

登录后复制

对象，就需要用到

getTime()

登录后复制

方法。

java.util.Date date = now.getTime();
System.out.println("转换为Date: " + date);

登录后复制

setTime()

登录后复制

：将Date对象设置为Calendar的时间 反过来，如果你有一个

java.util.Date

登录后复制

对象，想要用

Calendar

登录后复制

进行操作，就需要

setTime()

登录后复制

方法。

java.util.Date anotherDate = new java.util.Date(); // 获取当前Date
Calendar anotherCalendar = Calendar.getInstance();
anotherCalendar.setTime(anotherDate);
System.out.println("从Date设置的Calendar: " + anotherCalendar.getTime());

登录后复制

before()

登录后复制

,
after()
登录后复制
,
compareTo()
登录后复制
：比较Calendar实例这些方法用于比较两个

Calendar

登录后复制

实例的时间顺序。

before()

登录后复制

和

after()

登录后复制

返回布尔值，

compareTo()

登录后复制

则返回一个整数，表示它们的相对顺序（-1表示早于，0表示相等，1表示晚于）。

Calendar future = Calendar.getInstance();
future.add(Calendar.DAY_OF_MONTH, 1);

System.out.println("当前时间是否在未来时间之前? " + now.before(future));
System.out.println("未来时间是否在当前时间之后? " + future.after(now));
System.out.println("比较结果 (now vs future): " + now.compareTo(future)); // 应该返回-1

登录后复制

Java中Calendar与Date类的关系及常见转换误区有哪些？

java.util.Date

登录后复制

和

java.util.Calendar

登录后复制

在Java早期是处理日期时间的核心，但它们的设计哲学和用途有所不同。

Date

登录后复制

类在我看来，更像是一个时间戳的封装，它内部存储的是自1970年1月1日00:00:00 GMT以来的毫秒数，代表一个精确到毫秒的瞬间。而

Calendar

登录后复制

则是一个更高级、更抽象的工具，它能将这个时间戳解析成我们熟悉的年、月、日、时、分、秒等字段，并且提供了对这些字段进行操作（如增减、设置）的功能。

它们之间的关系可以这样理解：

Date

登录后复制

是“时间点”，而

Calendar

登录后复制

是“时间点解析器和操作器”。

常见转换误区：

Date的API误用： 很多人会尝试直接使用
```
Date
```
登录后复制
类中的
```
getYear()
```
登录后复制
、
```
getMonth()
```
登录后复制
等方法来获取日期字段。但这些方法在JDK 1.1之后就已经被废弃了，因为它们存在时区问题，并且月份从0开始计数等设计缺陷。正确的做法是，将
```
Date
```
登录后复制
对象转换为
```
Calendar
```
登录后复制
对象，再通过
```
Calendar
```
登录后复制
的
```
get()
```
登录后复制
方法获取各个字段。
```
// 错误示范 (已废弃且有时区问题)
// Date myDate = new Date();
// System.out.println(myDate.getYear() + 1900); // 废弃方法

// 正确做法
java.util.Date myDate = new java.util.Date();
Calendar calFromDate = Calendar.getInstance();
calFromDate.setTime(myDate);
System.out.println("年份: " + calFromDate.get(Calendar.YEAR));
```
登录后复制

Calendar的Mutability（可变性）： 这是我个人觉得

Calendar

登录后复制

最容易让人踩坑的地方。

Calendar

登录后复制

对象是可变的，这意味着当你对一个

Calendar

登录后复制

实例进行

add()

登录后复制

或

set()

登录后复制

操作时，它会直接修改自身的状态。如果你不小心将同一个

Calendar

登录后复制

实例传递给多个地方，或者在一个循环中重复使用，可能会导致意想不到的结果。

Calendar original = Calendar.getInstance();
Calendar modified = original; // modified和original指向同一个对象

modified.add(Calendar.DAY_OF_MONTH, 1);

System.out.println("原始Calendar (被修改了): " + original.getTime()); // original也被修改了

登录后复制

为了避免这种问题，当你需要基于一个

Calendar

登录后复制

对象进行操作但又不想改变原对象时，应该创建一个新的

Calendar

登录后复制

实例，或者克隆一份：

Calendar originalCorrect = Calendar.getInstance();
Calendar newCalendar = (Calendar) originalCorrect.clone(); // 克隆一份
// 或者
// Calendar newCalendar = Calendar.getInstance();
// newCalendar.setTime(originalCorrect.getTime());

newCalendar.add(Calendar.DAY_OF_MONTH, 1);
System.out.println("原始Calendar (未被修改): " + originalCorrect.getTime());
System.out.println("新Calendar (修改后): " + newCalendar.getTime());

登录后复制

为什么Java 8推荐使用java.time API，Calendar类还有哪些不可替代的场景？

Java 8引入的

java.time

登录后复制

包（通常称为JSR-310或新日期时间API）是对

Date

登录后复制

和

Calendar

登录后复制

类的一次彻底重构和现代化。在我看来，它的出现极大地简化了日期时间编程，解决了旧API中长期存在的痛点。

法语写作助手

法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。

查看详情

Calendar

登录后复制

类的主要缺点和
java.time
登录后复制
的优势：

可变性问题：
```
Calendar
```
登录后复制
对象是可变的，容易导致线程不安全和意外的副作用。
```
java.time
```
登录后复制
中的所有核心类（如
```
LocalDate
```
登录后复制
,
```
LocalTime
```
登录后复制
,
```
LocalDateTime
```
登录后复制
,
```
ZonedDateTime
```
登录后复制
等）都是不可变的，每次操作都会返回一个新的实例，这大大提高了代码的健壮性和可预测性。
API设计复杂且不直观：
```
Calendar
```
登录后复制
的月份从0开始，字段常量命名有时也让人困惑。
```
java.time
```
登录后复制
的API设计更加直观和语义化，例如
```
Month.JANUARY
```
登录后复制
代表1月，
```
plusDays()
```
登录后复制
、
```
minusHours()
```
登录后复制
等方法一目了然。
线程不安全：
```
Calendar
```
登录后复制
不是线程安全的，在多线程环境下需要额外的同步措施。
```
java.time
```
登录后复制
的不可变性使其天然就是线程安全的。
时区处理复杂：
```
Calendar
```
登录后复制
处理时区时，常常需要手动设置
```
TimeZone
```
登录后复制
，并且在夏令时切换时容易出错。
```
java.time
```
登录后复制
提供了
```
ZonedDateTime
```
登录后复制
等类，对时区和夏令时的处理更加清晰和健壮。
缺乏类型安全：
```
Calendar
```
登录后复制
的
```
get()
```
登录后复制
和
```
set()
```
登录后复制
方法都使用
```
int
```
登录后复制
类型的字段常量，容易混淆，也缺乏编译时检查。
```
java.time
```
登录后复制
则有更丰富的类型系统，例如
```
Duration
```
登录后复制
用于表示时间段，
```
Period
```
登录后复制
用于表示日期段。

Calendar

登录后复制

类不可替代的场景（或仍有其价值的场景）：

尽管

java.time

登录后复制

是现代Java开发的首选，但

Calendar

登录后复制

类并非一无是处，在某些特定场景下，它仍然有其用武之地：

遗留系统维护： 这是最主要的原因。在大量的现有Java项目中，
```
Calendar
```
登录后复制
类被广泛使用。重构这些代码以完全替换为
```
java.time
```
登录后复制
可能成本高昂且风险大。在这种情况下，理解并继续使用
```
Calendar
```
登录后复制
是必要的。
与旧API或第三方库交互： 某些第三方库或框架可能仍然期望或返回
```
java.util.Date
```
登录后复制
或
```
java.util.Calendar
```
登录后复制
对象。在这种接口边界，你可能需要进行转换。
某些特定功能：
```
Calendar
```
登录后复制
在处理某些特定需求时，例如计算某个日期是当年的第几周，或者获取星期的第一天等，虽然
```
java.time
```
登录后复制
也能实现，但
```
Calendar
```
登录后复制
可能因为其历史积累，在某些特定文化或地区习惯的日期计算上表现出一些便利性。不过，这通常可以通过
```
java.time
```
登录后复制
结合
```
TemporalAdjusters
```
登录后复制
和
```
Locale
```
登录后复制
更好地实现。
Java版本限制： 如果你的项目运行在Java 8之前的版本（比如Java 6或7），那么
```
java.time
```
登录后复制
API是不可用的，
```
Calendar
```
登录后复制
仍然是唯一的内置选择。

总的来说，对于新项目或有机会重构的模块，我强烈建议拥抱

java.time

登录后复制

。但在面对遗留代码时，对

Calendar

登录后复制

的熟练掌握依然是一项宝贵的技能。

Calendar类在处理时区和夏令时时需要注意哪些细节？

Calendar

登录后复制

类在处理时区和夏令时方面，确实有一些需要留心的细节，否则很容易引入难以发现的bug。在我看来，它在这方面的设计不如

java.time

登录后复制

那么直观和健壮，但理解其工作原理是关键。

1. 时区设置：

Calendar

登录后复制

实例在创建时，默认会使用JVM的默认时区。如果你需要处理特定时区的日期时间，就必须显式地设置

TimeZone

登录后复制

。

import java.util.Calendar;
import java.util.TimeZone;

Calendar gmtCalendar = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
System.out.println("GMT时间: " + gmtCalendar.getTime());

Calendar nyCalendar = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
System.out.println("纽约时间: " + nyCalendar.getTime());

// 你也可以在创建后设置
Calendar localCalendar = Calendar.getInstance();
System.out.println("本地时间: " + localCalendar.getTime());
localCalendar.setTimeZone(TimeZone.getTimeZone("Europe/London"));
System.out.println("设置为伦敦时区后: " + localCalendar.getTime()); // 注意，getTime()返回的Date对象内部仍是UTC毫秒数，只是Calendar在格式化时会用伦敦时区规则

登录后复制

注意：

Calendar

登录后复制

内部存储的其实是自Epoch（1970-01-01 00:00:00 GMT）以来的毫秒数，这个毫秒数是与时区无关的。当你设置了

TimeZone

登录后复制

后，

Calendar

登录后复制

会根据这个时区规则来解释和计算这些毫秒数，从而得到年、月、日、时、分等字段。

getTime()

登录后复制

方法返回的

Date

登录后复制

对象，其内部仍然是这个UTC毫秒数。当你打印

Date

登录后复制

对象时，JVM通常会用默认时区来格式化它。这常常是初学者感到困惑的地方。

2. 夏令时（Daylight Saving Time, DST）的处理：

Calendar

登录后复制

类本身是能够自动处理夏令时的。当你设置一个日期时间，并且该日期时间落在夏令时生效或结束的区域和时间段内时，

Calendar

登录后复制

会自动调整时间。

例如，在许多地区，夏令时开始时，时间会向前跳一个小时（比如凌晨2点变成凌晨3点）；夏令时结束时，时间会向后跳一个小时（比如凌晨2点变成凌晨1点）。

Calendar dstStart = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
// 设置一个夏令时开始前的时间 (假设纽约夏令时在3月第二个周日凌晨2点开始)
dstStart.set(2023, Calendar.MARCH, 12, 1, 30, 0); // 2023年3月12日1:30 AM
System.out.println("夏令时开始前: " + dstStart.getTime()); // 输出1:30 AM EST

dstStart.add(Calendar.HOUR_OF_DAY, 1); // 增加一个小时
System.out.println("增加一小时后 (跨越夏令时开始): " + dstStart.getTime()); // 可能会跳到3:30 AM EDT，而不是2:30 AM EST

登录后复制

这里需要注意的是，

add()

登录后复制

方法在跨越夏令时边界时，会根据时区规则进行“智能”调整。例如，如果你在夏令时开始前一小时，

add(Calendar.HOUR_OF_DAY, 1)

登录后复制

，结果可能会直接跳过夏令时开始时“丢失”的那一小时。

潜在问题和注意事项：

“缺失”或“重复”的时间： 在夏令时开始时，会有一个小时的时间段在钟表上是不存在的（例如，从1:59 AM直接跳到3:00 AM）。如果你试图设置或计算这个“缺失”的时间，
```
Calendar
```
登录后复制
可能会将其调整到夏令时生效后的时间。相反，在夏令时结束时，会有一个小时的时间段重复出现（例如，从1:00 AM到1:59 AM会发生两次）。
```
Calendar
```
登录后复制
在处理重复时间时，可能会根据其内部实现选择第一个或第二个实例。这在需要精确时间戳的场景下可能导致问题。
跨时区计算： 当你在不同时区之间进行日期时间计算时，务必确保每个
```
Calendar
```
登录后复制
实例都设置了正确的
```
TimeZone
```
登录后复制
，并且理解
```
getTime()
```
登录后复制
返回的
```
Date
```
登录后复制
对象是UTC毫秒数，它的字符串表示取决于JVM的默认时区或你使用的
```
DateFormat
```
登录后复制
。
TimeZone数据库更新： 时区规则（包括夏令时规则）会不定期发生变化。JVM内部维护一个时区数据库。如果你的JVM时区数据库过旧，可能会导致夏令时计算错误。定期更新JVM或使用
```
java.time
```
登录后复制
（它通常依赖于更现代的TZDB）可以缓解这个问题。