On Mar 20, 2013, at 3:05 PM, Henrik Johansen wrote:
On Mar 20, 2013, at 2:52 PM, Henrik Johansen wrote:
Yeah, seems to be in the resolver of the whole family of year:* constructors. Attached a fix, as I have no idea how to do the new issue tracking, and couldn't find a tutorial on the website.
<DateAndTime class-yearmonthdayhourminutesecondnanoSecondoffset.st> Scratch that, definitely not my day today :)
Cheers, Henry
Assuming the instvars are indeed now meant to hold UTC-values, here's some more thorough feedback (related to issues occurring around midnight): - Time initialization uses seconds from primSecondsClock (which returns local time) to set DaysSinceEpoch, with a constructor that expects UTC (in other words, it sets julianDayNumber directly). I couldn't find any accessors in the image, but I think there's new UTC clock primitives available? - todayAtMilliSeconds: / todayAtNanoSeconds: use this cached value without doing any checks, so unless someone calls milliSecondsSinceMidnight (which does the correct checking), they will return false results regardless when clock passes over. Incorrect direct uses of julianDayNumber instvar: - #hasEqualTicks: compares julianDayNumber directly vs other instances julianDayNumber, rather than julianDayNumberUTC. - same for #< Cheers, Henry