Date has a smal bug
-
// // Reading and writing // public Date(ByteQueue queue) { readTag(queue); year = queue.popU1B() + 1900; month = Month.valueOf(queue.pop()); day = queue.popU1B(); dayOfWeek = DayOfWeek.valueOf(queue.pop()); }
the fix offset of 1900 is wrong.
it should be:int tmpyear = queue.popU1B(); if (tmpyear != 255) { tmpyear += 1900; } year = tmpyear;
else the function isYearUnspecified will never return true.
causes a glitch when displaying an unspecified year.regards
robert -
also
@Override public void writeImpl(ByteQueue queue) { int shortYear = year; if (shortYear > 1900) { shortYear -= 1900; }
-
I don't recall now why the Date class is storing a +1900 year value internally anyway. Maybe it should just use 0-255 internally and provide convenience methods for +1900?
-
How's this:
public Date(int year, Month month, int day, DayOfWeek dayOfWeek) { if (year > 1900) year -= 1900; else if (year == -1) year = 255; if (day == -1) day = 255; this.year = year; this.month = month; this.day = day; this.dayOfWeek = dayOfWeek; }
public Date(GregorianCalendar now) { this.year = now.get(Calendar.YEAR) - 1900; this.month = Month.valueOf((byte) (now.get(Calendar.MONTH) + 1)); this.day = now.get(Calendar.DATE); this.dayOfWeek = DayOfWeek.valueOf((byte) (((now.get(Calendar.DAY_OF_WEEK) + 5) % 7) + 1)); }
public int getCenturyYear() { return year + 1900; }
public Date(ByteQueue queue) { readTag(queue); year = queue.popU1B(); month = Month.valueOf(queue.pop()); day = queue.popU1B(); dayOfWeek = DayOfWeek.valueOf(queue.pop()); } @Override public void writeImpl(ByteQueue queue) { queue.push(year); queue.push(month.getId()); queue.push((byte) day); queue.push(dayOfWeek.getId()); }
-
What a coincidence, I came online to report the exact same thing, as my schedules were being created with the wrong year for the effective date range when I used unspecified.
I've tried your modifications, and they do the trick.
I don't recall now why the Date class is storing a +1900 year value internally anyway. Maybe it should just use 0-255 internally and provide convenience methods for +1900? Agreed. I think that would be the most sensible solution
-