On 20 Mar 2013, at 19:40, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2013/3/20 Sven Van Caekenberghe <sven@stfx.eu>:
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.
I don't adhere. Don't waste time documenting a bad feature, if these are two different things just use to different names.
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
Yes, sorry, my participation to the process dropped. You must not count on it, it's only a little part of my own free time. It's free, but not reliable. My little contribution logically comes after the release mainly for these reasons 1) my previous attempts to catch up with 2.0 were abandonned because deep changes were going on, a bit too much instability for too little time 2) the buzz convinced me to try again on a more stabilized image
The failing tests amazed me a little because we now have CI to perform this kind of dumb job.
Last thing, continuous improvment certainly, but I'm not comfortable with the process. More than often it is necessary to download a fresh image which is fine for a bot but is a barrier for me. Probably because my stuff is just a blob of hacks, proof of concepts or unfinished experiments, and I don't invest time into producing re-installable artifacts. It happens that I publish revisited stuff that is one or two years old, so I don't like to throw too soon. And I want to keep those hacks alive, not to bury them into a dead fileOut or mcz. My own view of continuous is closer to the smooth updates of Squeak trunk.
I'd like to contribute more, and I hope you will retain the positive part, because most certainly I will mainly report the things I don't like ;)
We absolutely value your contributions, of any kind, Nicolas, I think you know that. Keep them coming. And yes, of course, it is entirely up to you how you spend your free time. Regards, Sven
cheers
Nicolas
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill