Hi Stef Me and Lukas just resolved the issue. It's not really a bug (although having two hard coded epochs seems a bit silly to me); the problem was in my code and the offset is time zone related. This means: my problem is solved and no bug report needs to be opened. Maybe at some point somone might consider a refactoring though... :)
Thanks, Max On 19.07.2010, at 13:07, Stéphane Ducasse wrote: > Dear Max > > Right now I do not know. > > which version are you using? > > Stef > > >> Hi. >> >> Evaluating: >> >> DateAndTime now asUnixTime >> >> and then creating a DateAndTime object from the result: >> >> DateAndTime fromUnixTime: <seconds> >> >> does not yield an equivalent object. As far as I can tell, this is because >> the unix epoch is hard coded in two places: >> >> DateAndTime class>>unixEpoch >> "Answer a DateAndTime representing the Unix epoch (1 January 1970, >> midnight UTC)" >> ^ self basicNew >> ticks: #(2440588 0 0) offset: Duration zero; >> yourself. >> >> DateAndTime>>fromUnixTime: anInteger >> ^ self fromSeconds: anInteger + >> 2177452800 "unix epoch constant" >> >> So in the end I get a difference of 7200 seconds. >> >> I'll gladly open up a bug but can someone please confirm that this is >> actually a bug and that I didn't miss something? >> >> Cheers, >> Max >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
