+1
giorgio
On Wed, Apr 29, 2020 at 9:26 PM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
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@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@gmail.com wrote:
Hi Chris, Hi Dave,
On Apr 28, 2020, at 5:53 PM, Chris Muller asqueaker@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.
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