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
>