On Mon, Mar 26, 2012 at 08:17:17PM -0700, Sean P. DeNigris wrote:
> 
> 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...

(cc to squeak-dev)

The Squeak Chronology system has limited ability to deal with time
zone offsets, which are not static offsets but vary as a function of
time for any given time zone. The problem you are seeing here is not
a single bug, it is one of many symptoms of this limited implementation.

See TimeZoneDatabase on SqueakSource for one way to address this:
  http://wiki.squeak.org/squeak/1076

Chronos is another implementation:
  http://chronos-st.org/

The current implementation with fixed offsets is simple and fast,
so you may consider the limited implementation to be either a bug
or a feature depending on your use case ;)

Dave