+1

giorgio

On Wed, Apr 29, 2020 at 9:26 PM Nicolas Cellier <
nicolas.cellier.aka.nice at 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 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/0c67c048/attachment.html>