That remind me in 1999, my company was distributing a software built on
Visualworks.
The main client asked for an analysis of robustness to Y2K.
I gave an analysis explaining in details why  there were no bug to be
expected.
As a reward for delivering good software, I've got nothing, not even a
thank you...
I later learned that my client had a budget for helping main software
providers to fix their own bugs!

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.
And let the client pay for upgrades ;)

Le mer. 29 avr. 2020 à 21:14, David T. Lewis <lewis at mail.msen.com> a écrit :

> It should be a great party, I'll put it on my calendar!
>
> But the year 60,000 shouldn't be a problem for programmers. All we need
> to do is get everybody to start using sensible software such as Squeak:
>
>   '60000-01-01T00:00:00-00:00' asDateAndTime ==> 60000-01-01T00:00:00+00:00
>
> Of course, from what I know about programmers, it will probably take
> another 60,000 years to convince them to start using sensible software.
>
> ;-)
> Dave
>
>
> On Wed, Apr 29, 2020 at 11:02:17AM -0400, Ron Teitelbaum wrote:
> > Can I just say now that I think the year 60,000 will be a bad year for
> > programmers!
> >
> > (Sorry couldn't resist.  We're gonna party like it's Fifty Nine Nine
> > Ninety Nine!)
> >
> > Ron
> >
> > On Wed, Apr 29, 2020 at 5:18 AM Eliot Miranda <eliot.miranda at gmail.com>
> > wrote:
> >
> > > Hi Chris, Hi Dave,
> > >
> > > > On Apr 28, 2020, at 5:53 PM, Chris Muller <asqueaker at gmail.com>
> wrote:
> > > >
> > > > ???
> > > > I have a bunch of two-element Array log entries, where the first
> element
> > > is the timestamp, the second is the object being logged.  But these
> entries
> > > may never be consumed, so I wish to minimize their cost.  So, instead
> of
> > > storing the timestamps as DateAndTimes, I wanted to keep them as
> > > SmallIntegers.  I thought I could use Time utcMicroseconds, now a
> > > SmallInteger in 64-bit Squeak.
> > > >
> > > > However, when I went to instantiate the DateAndTime lazily from that
> > > number it's said it's year 2089...
> > > >
> > > >         DateAndTime utcMicroseconds: Time utcMicrosecondClock
> offset: 0
> > >    " 2089-04-29T00:49:26.3326+00:00"
> > >
> > > I gave yo say that this is a bug.  Dave, I know you have affection for
> the
> > > posix epoch but the system uses the Smalltalk epoch, the start of the
> 20th
> > > c, and the utcMucroseconds primitive answers microseconds from that
> epoch,
> > > not the posix epoch.  And it???s good for some 58,000 years before it
> > > overflows 61-bit SmallIntegers (there are three tag bits) so there???s
> > > essentially nothing to be gained from using the posix epoch.
> > >
> > > Now the posix epoch is important; and we should support it.  But we
> should
> > > clearly indicate it in spud, eg by having the word posix in the
> selector
> > > somewhere.
> > >
> > > So the method should be renamed either utcPosixMicroseconds:offset: or
> > > posixUTCMicroseconds:offset:, and utcMicroseconds:offset: should go
> what
> > > Chris expects.  The principle of least astonishment says it must be so.
> > >
> > >
> > > >
> > > > I realized this is because a different epoch being used (1901 vs.
> 1971)
> > > between the two.  This seems inconsistent and confusing, but that's
> less
> > > important to me at the moment than the efficiency I'm looking for.  Is
> > > there another way?
> > > >
> > > >  - Chris
> > > >
> > >
> > >
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200429/de8ce2ae/attachment.html>