On 20 Mar 2013, at 14:01, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote:
Totally agree, but for this specific bug I think that the process can be improved by increased code reviews. The fact that a negative seconds inst var and a julianDayNumber inst var different from julianDayNumber message was chosen indicates that current implementation is a quick hack, a workaround for solving some problems, but clearly not a long term solution. IMO it creates as many problems as it solves.
That is a totally different discussion and most probably the tests are wrong, as with most of the date and time stuff from squeak. The dimensions of this mess are hard to grasp, but using a reference point expressed in local time is a very bad thing. So we changed that and all internal representations of DateAndTime are in UTC. All external representations of DateAndTime are in local time.
That implies that whatever you inspect and see is in UTC, negative offsets make perfectly sense if your time-zone lags behind UTC. I wish I had time to fully clear up the mess, and add all basic accessors for utc.
Nicolas wasn't talking of offset.
When I (in Norwegian timezone) do DateAndTime midnight
I get an instance with instvars: seconds -3600 offset: 1 hour duration.
If it were indeed supposed to return local time instvar, I would expect an instance with julianDayNumber one less, and seconds 23 *3600.
Cheers, Henry
Maybe renaming the instance variables to reflect their UTC nature would help, but there is a difference between internal representation and external behaviour - if it is documented that seems OK to me. The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. Constructive criticism is always welcome, but these changes to DateAndTime were made many months ago - with great effort. Yes, there is still work to be done, and although it is maybe logical, it is a bit dissappointing to hear it right after a release. Pharo is a continuous improvement process. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill