Android 这是安卓系统中的一个bug吗?

Android 这是安卓系统中的一个bug吗?,android,debugging,gregorian-calendar,Android,Debugging,Gregorian Calendar,现在是2015年1月26日,我在安卓设备上运行了以下代码: GregorianCalendar date = new GregorianCalendar(); SimpleDateFormat df = new SimpleDateFormat(); // Set date to 4 weeks ago, and then use it for the first BETWEEN date in the above query date.set(GregorianCalendar.WE

现在是2015年1月26日,我在安卓设备上运行了以下代码:

GregorianCalendar date = new GregorianCalendar();
SimpleDateFormat df = new SimpleDateFormat();

// Set date to 4 weeks ago, and then use it for the first BETWEEN date in the above query    
date.set(GregorianCalendar.WEEK_OF_YEAR, date.get(GregorianCalendar.WEEK_OF_YEAR)-4);
System.out.println(df.format(new Date(date.getTimeInMillis())));
// Set date to 2 weeks time, and then use it for the second BETWEEN date in the above query

date.set(GregorianCalendar.WEEK_OF_YEAR, date.get(GregorianCalendar.WEEK_OF_YEAR)+6);
System.out.println(df.format(new Date(date.getTimeInMillis())));
我得到了输出

29/12/14 10:29
09/02/14 10:29
在Windows计算机上的标准Java上运行此代码段将显示正确的结果,第二个日期为
09/02/15 10:29
。因此,在Android上,当我们要求日期倒退4周时,它是正确的向后滚动一年,但当我们要求它向前滚动6周(超过我们最初的日期)时,它不是再次向前滚动一年

我在5.0.2和4.4.2中观察到了这一点


所以问题是,这是一个bug还是某种复杂的预期行为(功能)?

您不应该使用
日历。为此设置
。您正试图将week字段设置为无效值,并希望它能够理解您的预期含义。这可能适用于桌面JVM,但您不应该依赖它,而且很明显,Android的实现确实以不同的方式处理它

使用
Calendar.add
,这实际上是您想要的:通过适当的调整对字段进行添加或减去

date.add(GregorianCalendar.WEEK_OF_YEAR, -4);
date.add(GregorianCalendar.WEEK_OF_YEAR, 6);

我敢肯定,某些
Calendar
字段的计算和处理是非常复杂的,这不是一个bug。事实上,您正在使用算术调整而不是使用
add(…)
方法也可能使事情变得复杂

从文件中

一个月或一年的第一周定义为从getFirstDayOfWeek()开始并至少包含该月或一年的getMinimalDaysInFirstWeek()天的最早七天期间

在这种情况下,一年中的第一周,即一年中的第一周=1
,从1月4日或5日开始,具体取决于一周中的第一天是否分别设置为周日或周一

日历类是抽象的,扩展它的具体类的不同实现可能会有不同的行为,但允许在一年中的几周内索引为0甚至-1。事实上,日期1->3或1->4(取决于一周的第一天)明显在2015年内,这意味着从12月28日或29日开始的一周被归类为第0周

1月26日属于
WEEK\u of u YEAR=4
(不考虑一周的第一天),因此当您从当前
WEEK\u of u YEAR
中减去4时,它返回0并将日期调整到该周的周一,即12月29日


当你在之前调整的日期基础上再增加6周时,问题就来了——此时是2014年12月29日。正如我所说,您使用的是算术调整,而不是
add(…)
方法。由于您没有手动调整年份,因此它假定年份应保持在2014年内,并且通过增加6周,您将导致溢出/回滚到2014年初,而不是动态调整
年份
以及
年度
周等。

谢谢。这不是我想要的答案,但这是我需要的答案。我接受了,因为这解释了我看到的奇怪结果,并回答了直接的问题。谢谢。@Rudi:很高兴我能透露一些情况。关键思想是,任何使用
\u OF
命名的字段(例如
小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时小时。这很棘手,正如我所说,它不是一个bug,更像是一个怪事。