Sean, I discovered that 2 month ago and did not make a submission. I fixed it by not relying on julianDay when using epoch. It is
DateAndTime class>>epoch
"Answer a DateAndTime representing the Squeak epoch: 1 January 1901 in
UTC timezone"
^ self basicNew
ticks: SqueakEpoch days ticks offset: Duration zero;
yourself
I wanted to submit the fix but then a few tests fail with this change. One test
I identified that coded the wrong assumption about duration into the test. But
then I didn't find enough time to fix the rest.
I attach what I've got so far. It is the change and a test that tests the
shift. Sorry for not submitting that earlier. It is a fix for 1.3
norbert
epochtest.1.cs
Description: Binary data
Am 27.03.2012 um 05:17 schrieb Sean P. DeNigris: > > Max Leske wrote >> >> DateAndTime fromUnixTime: <seconds> >> >> DateAndTime>>fromUnixTime: anInteger >> ^ self fromSeconds: anInteger + >> 2177452800 "unix epoch constant" >> > > This seems like a bug to me. Wikipedia defines unix epoch time as "the > number of seconds elapsed since midnight Coordinated Universal Time > (UTC)..." > > However, #fromSeconds: takes the resulting time and simply tacks on the > local offset. For example, it makes 12:02pm+0hrs into 12:02pm-4hrs (for NY). > > I scraped a unix time from an html page, and put it into Pharo. The unix > time was based (correctly as defined above) on UTC, so in this case, it > should have done: > 12:02pm+0hrs -> 8:02am-4hrs > instead of > 12:02pm+0hrs -> 12:02pm-4hrs > > To get the correct result now, one has to jump through hoops like: > DateAndTime fromUnixTime: (1332807176 + DateAndTime localOffset asSeconds). > or > ((DateAndTime fromUnixTime: 1332807176) offset: Duration zero) asLocal > > Does all this sound right? If so, I'll create an issue for it... > > Sean > > -- > View this message in context: > http://forum.world.st/Bug-in-DateAndTime-tp2293749p4507847.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
