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