<div dir="ltr"><div>That remind me in 1999, my company was distributing a software built on Visualworks.</div><div>The main client asked for an analysis of robustness to Y2K.</div><div>I gave an analysis explaining in details why  there were no bug to be expected.</div><div>As a reward for delivering good software, I've got nothing, not even a thank you...</div><div>I later learned that my client had a budget for helping main software providers to fix their own bugs!</div><div><br></div><div>I learned that: if you want to earn money in this industry, do deliver crappy code, just above the deal-breaker level, but no more.</div><div>And let the client pay for upgrades ;)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 29 avr. 2020 à 21:14, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It should be a great party, I'll put it on my calendar!<br>
<br>
But the year 60,000 shouldn't be a problem for programmers. All we need<br>
to do is get everybody to start using sensible software such as Squeak:<br>
<br>
  '60000-01-01T00:00:00-00:00' asDateAndTime ==> 60000-01-01T00:00:00+00:00<br>
<br>
Of course, from what I know about programmers, it will probably take<br>
another 60,000 years to convince them to start using sensible software.<br>
<br>
;-)<br>
Dave<br>
<br>
<br>
On Wed, Apr 29, 2020 at 11:02:17AM -0400, Ron Teitelbaum wrote:<br>
> Can I just say now that I think the year 60,000 will be a bad year for<br>
> programmers!<br>
> <br>
> (Sorry couldn't resist.  We're gonna party like it's Fifty Nine Nine<br>
> Ninety Nine!)<br>
> <br>
> Ron<br>
> <br>
> On Wed, Apr 29, 2020 at 5:18 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>><br>
> wrote:<br>
> <br>
> > Hi Chris, Hi Dave,<br>
> ><br>
> > > On Apr 28, 2020, at 5:53 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> > ><br>
> > > ???<br>
> > > I have a bunch of two-element Array log entries, where the first element<br>
> > is the timestamp, the second is the object being logged.  But these entries<br>
> > may never be consumed, so I wish to minimize their cost.  So, instead of<br>
> > storing the timestamps as DateAndTimes, I wanted to keep them as<br>
> > SmallIntegers.  I thought I could use Time utcMicroseconds, now a<br>
> > SmallInteger in 64-bit Squeak.<br>
> > ><br>
> > > However, when I went to instantiate the DateAndTime lazily from that<br>
> > number it's said it's year 2089...<br>
> > ><br>
> > >         DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0<br>
> >    " 2089-04-29T00:49:26.3326+00:00"<br>
> ><br>
> > I gave yo say that this is a bug.  Dave, I know you have affection for the<br>
> > posix epoch but the system uses the Smalltalk epoch, the start of the 20th<br>
> > c, and the utcMucroseconds primitive answers microseconds from that epoch,<br>
> > not the posix epoch.  And it???s good for some 58,000 years before it<br>
> > overflows 61-bit SmallIntegers (there are three tag bits) so there???s<br>
> > essentially nothing to be gained from using the posix epoch.<br>
> ><br>
> > Now the posix epoch is important; and we should support it.  But we should<br>
> > clearly indicate it in spud, eg by having the word posix in the selector<br>
> > somewhere.<br>
> ><br>
> > So the method should be renamed either utcPosixMicroseconds:offset: or<br>
> > posixUTCMicroseconds:offset:, and utcMicroseconds:offset: should go what<br>
> > Chris expects.  The principle of least astonishment says it must be so.<br>
> ><br>
> ><br>
> > ><br>
> > > I realized this is because a different epoch being used (1901 vs. 1971)<br>
> > between the two.  This seems inconsistent and confusing, but that's less<br>
> > important to me at the moment than the efficiency I'm looking for.  Is<br>
> > there another way?<br>
> > ><br>
> > >  - Chris<br>
> > ><br>
> ><br>
> ><br>
<br>
> <br>
<br>
<br>
</blockquote></div>