On Fri, Jul 08, 2016 at 09:11:46PM -0500, Chris Muller wrote:
> Eliot, I'm not against your suggestion about seconds:, but there is no
> way you should have to mutate an object for sake of only printing it.
> It should merely be the responsibility of the printing to meet the
> needed requirement.

+1

Dave

> 
> On Fri, Jul 8, 2016 at 12:49 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Hi All,
> >
> > On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > Hi All,
> >
> >     how does one produce a nice timestamp, simply date and time as in
> >
> >     7/7/2016 09:19:38
> >
> > Trivial, right?
> >
> > So
> >
> >     Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
> >
> > .914, ah, nanos.  How useful.  Let's get rid of them.  No nanos: accessor so
> >
> >     Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
> >
> > but there's a seconds accessor, so
> >
> >     Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24)
> > '7/7/2016 00:00:41
> >
> > ??  So seconds: is private, and isn't the dual of Time seconds:
> >
> > Time seconds
> > ^ self second
> > Time second
> > ^ self asDuration seconds
> > Duration seconds
> > "Answer the number of seconds the receiver represents."
> > ^seconds rem: SecondsInMinute
> >
> > Looks broken to me.
> >
> >
> > Let me be more explicit, and ask for permission to fix this.  One basic bug
> > is the asymmetry between seconds, an accessor that answers seconds mod 60,
> > and seconds: that doesn't set seconds mod 60.  But seconds: is private and
> > could be replaced by eg setTotalSeconds:, presumably without breaking
> > clients, allowing seconds: to be redefined to do the right thing.
> >
> > I note that the historic bug of changing the semantics of Time now to answer
> > something with finer resolution than one second could have been avoided by
> > adding eg exactlyNow or preciselyNow.
> >
> > The problem with nanos (apart from the horrible abbreviation) is that it
> > presumes a maximum precision that isn't well chosen.  Microseconds work out
> > much better.  And I hope we change the internal representation accordingly.
> > But there needs to be done accessor that rounds to the nearest second
> > without revealing the internal precision.  Time now toTheNearestSecond or
> > Time theNearestSecondNow or...?
> >
> >
> > Personally I think print24 should not print sub seconds.
> >
> > cc'ing to Pharo because I want this timestamp to be the same in both
> > dialects for a profiling tool we want to use in both dialects.
> > _,,,^..^,,,_
> > best, Eliot
> >
> >
> >
> >