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
