问题中的第二个输出是在运行爱尔兰时间（欧洲/都柏林）的JVM上的正确预期行为。2017年9月12日，爱尔兰开始夏令时（DST）。尽管没有明确记录，但
Date.toString()（在打印时
Date从中隐式调用
c.getTime()）在JVM的时区中打印日期和时间，该时间和日期在9月被表示为爱尔兰夏令时的IST。
当您
Calendar还使用爱尔兰时间在对象上设置日期时，将保留一天中的小时；就您而言，您将获得Jan 01 2007
12:36:24爱尔兰标准时间。现在想象一下，如果将爱尔兰夏令时和爱尔兰标准时间都渲染为IST会造成混淆。您将无法区分。相反，由于爱尔兰的标准时间与格林尼治标准时间一致，因此
Date.toString()当日期
不在 一年中的夏令时（不是一月）时，将显示此内容。
我的猜测是您的第一个输出来自运行印度时间的JVM。它也被渲染为IST，并且由于印度不使用夏季时间，所以夏季和冬季都使用相同的缩写。
java.time
在了解对您观察到的行为的解释之前，我发表了有关过时的Java日期和时间类的评论。不过，我仍然认为评论不会遥遥无期。这是代码的现代等效项：
ZonedDateTime zdt = ZonedDateTime.now(ZoneId.of("Europe/Dublin")); System.out.println(zdt); zdt = zdt.with(LocalDate.of(2007, Month.JANUARY, 1)); System.out.println(zdt);它打印
2017-09-12T11:45:33.921+01:00[Europe/Dublin]2007-01-01T11:45:33.921Z[Europe/Dublin]
如果要使用JVM的时区设置，请使用
ZoneId.systemDefault()代替
ZoneId.of("Europe/Dublin")。顾名思义，与相反Date，
ZonedDateTime确实包含时区。它更符合旧
Calendar类别。如您所见，其
toString方法
Z以明确的
区域/城市
格式打印UTC的偏移量（表示零偏移量）和时区名称。我相信这会减少混乱的余地。如果要以特定格式打印日期，请使用
DateTimeFormatter。
附录：代码示例输出
为了完整起见，这是运行不同时区（可能呈现为IST）时代码的输出：
欧洲/都柏林（同意您的第二项输出）
Tue Sep 12 11:19:28 IST 2017
Mon Jan 01 11:19:28 GMT 2007
亚洲/特拉维夫
Tue Sep 12 13:19:28 IDT 2017
Mon Jan 01 13:19:28 IST 2007
亚洲/加尔各答（同意您的第一个输出）
Tue Sep 12 15:49:28 IST 2017
Mon Jan 01 15:49:28 IST 2007
