Great, thank you :-)

Dave

On Fri, Mar 06, 2020 at 11:35:57PM +0000, Robert via Squeak-dev wrote:
> Hey Dave, The version I ended up publishing was with a call to 
> #nanoseconds! This was the issue. So we took different paths and arrived 
> together! This fixed all the DateAndTime issues and we got Crypto 
> published in v5.3. I believe the latest is 120.
> 
> Though the versions are different, for readFrom:, they may well work the 
> same. I would consider it untested, but no cause for alarm. Seems to 
> work for my uses!
> 
> k, r
> 
> On 3/6/20 6:30 PM, David T. Lewis wrote:
> > Hi Robert,
> >
> > I know this is no longer an issue for Cryptography, but I am responsible
> > for the new internal representation of DateAndTime, so I want to follow
> > up in case there are any remaining concerns.
> >
> > On Mon, Mar 02, 2020 at 05:55:20PM +0000, Robert via Squeak-dev wrote:
> >> Yes, my former method extension DateAndTime>>#milliSecond accessed
> >> #nanos.  > I changed this to call #utcMicroseconds and changed the
> >> name o fthe method to #milliseconds. This is in version 117 of
> >> Cryptography that I had released.
> > The accessor method for this is DateAndTime>>nanosecond. The #nanos
> > instance variable no longer exists, but #nanosecond produces the same
> > results as before and passes all unit tests. If you were to change your
> > method to use self nanosecond rather than direct reference to the
> > instance variable, then it should work as you expect.
> >
> >> The remaining issue is DateAndtime class>>#readFrom: which completely
> >> changed implementations and also produced different results. This is
> >> a failure of DateAndTime to migrate to a new internal representation,
> >> while preserving identical results to former behavior. There are two
> >> representations of DateAndTime in tthe test method under discussion.
> >> One is the ASN1 representation and the other is an internet task force
> >> accepted textual representation. The new #readFrom: misrepresents the
> >> result from the textual  representation. This is a clear error in core
> >> DateAndTime, IMHO. The milliseconds are different, somehow.
> >>
> > Can you say specifically what was different versus the former behavior?
> > There definitely are differences in the new implementation, but my
> > expectation is that any differences should either fix problems or
> > resolve ambiguities.
> >
> > Thanks,
> > Dave
> >
> 
>