Smalltalk › Squeak › Squeak - Dev

open paren/brace/bracket...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

Igor Stasenko

Re: open paren/brace/bracket...

On 18 April 2014 05:11, Chris Muller <[hidden email]> wrote:

Thanks for that great explanation -- (my interest in in man-machine
interfaces has always made this an interesting topic for me).

I've got to say, I totally get you. I know exactly how you feel
because its exactly how I feel about "Auto Indent". I drives me nuts
in exactly the ways you've described about Auto Enclose, and for the
same exact reasons. It totally intrudes on my typing, disrupting my
train of thought because its guessing wrong half the time and forcing
me into a bunch of little "decisions" whether I need to press Tab or
Backspace. I know what I want to type, I just want to let-it-flow.

This made me pause to ask, "so why do I like Auto Enclose so much, but
not Auto Indent?"

It's because of Squeak's amazing little collection of 2 or 3 editing
features turn it into like a poor-mans Scratch. You know, the ones
we've been talking about: 1) selecting innards, 2) hot-key
adding/removing of surrounding enclosures, 3) auto format. Once using
those, Auto Enclose rounds it out nicely, (and disabling
selectionMayShrink boosts it even one more notch).

>> You know, I bet this boils down to a simple cost-benefit analysis. For me,
>> the effort required to
>> type a character at the cursor position is negligible, so saving that
>> effort is of little benefit. Even
>> in cases where I will need to put a $) after the expression I'm typing
>> now, sometimes I'll have to
>> type right-arrow to get past it. So the benefit is very small and often
>> offset by a small loss.

It's not about saving keystrokes. It's about automatic closure of
multiple nested expressions. Query's like this are almost impossible
to "type" without Auto Enclose:

Usually, when this happens, this is a good sign that your code needs refactoring.

^ (cube
plot: [ : dim | dim date month ]
measures:
[ : meas |
(meas mean score plotNumber: 1)
, ((meas
define: #fractionOfWinners
as: [ : cell | cell total winnerCount / cell total
count ]) plotNumber: 2)
, (meas mean gainFactor
plotNumber: 3;
colorizer: [ : val | val > 0 ifTrue: [Color green
twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ]
where:
[ : cell |
(cell dimension date year equalTo: Date today asYear)
| (cell dimension date year equalTo: Date today asYear
previous) ]) open

It'd be much more easily "assembled", expression by expression, but
Auto Enclose gives typing it at least a chance of success. :)

>> Similarly, deleting an unwanted character is cheap, but deciding whether
>> to do so is a huge cost.
>> I have to stop thinking about what I'm doing, and think ahead to what I'm
>> going to do next. Even
>> if I know I'm going to need the closing character, it stays in my field of
>> view and takes up cycles
>> as a pending thing that I have to worry about until I complete the encoded
>> expression.

So I'm surprised you don't better appreciate the atomicity of
expression-editing. Deleting a paren/brace/quote character breaks the
code and even breaks the formatter so you can get really stuck on
complex expressions. Taking an approach of expression-editing, one is
determined not to let the code ever be broken even for a short period
of time.

>> So, the benefit is small and unreliable, while the cost is large and
>> inevitable. It forces me to think
>> about typing, which normally I don't have to do. Thus, it's infuriating.

Yep, I totally get you. But if you ever decide to try committing to
Squeak's very capable expression-editing functions, I hope it'll work
out as well for you as for me.

--
Best regards,
Igor Stasenko.

David T. Lewis

Some DateAndTime experiments

I have been experimenting with a new implementation of DateAndTime based
on a UTC magnitude. In this implementation, the instance variables jdn,
seconds, and nanos are replaced with a single utcMicroseconds, and the
offset (a Duration) is replaced by localOffsetSeconds (an integer). The
UTC magnitude and offset are provided directly by primitiveUtcWithOffset
when doing DateAndTime now.

I had hoped to achieve a sigificant performance advantage with this
implementation, and while it does improve performance, I am only seeing
about a 10% improvement overall, which is considerably less than I had hoped.
Nevertheless, it is indeed faster, and implemention does have some interesting
characteristics.

The utcMicroseconds magnitude is in units of microseconds, but it is not
required to be an integer and may represent time to any precision. In practice,
values are integral unless the instance is explicitly created with a nanosecond
value.

New instances created by "DateAndTime now" will have the correct time zone
offset as provided by the operating system platform, and their magnitude is
set to a UTC value the precision provided by the platform.

New instances created by other constructors use TimeZone default, which is
problematic given that the time zone in Squeak may or may not match the
(presumably correct) values provided by the operating system.

Instances of DateAndTime are (at the moment) considered equal if their magnitudes
are the same, independent of the time zone offset. This makes sense when thinking
of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances
with different local offsets are equal might be wrong in other contexts.

The localOffsetSeconds is used for displaying the date and time, and is not
related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a
formatter (use the offset to show the magnitude in the context of a local
time zone).

Dave

Nicolas Cellier

Re: Some DateAndTime experiments

Hi Dave,
did you lurk at the work in Pharo?

I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively.

It would be interesting to compare the timings vs latest Pharo (3.0).

A single variable is interesting for simplifying implementation.
I wonder about the required precision though...
There are about 2^20 microseconds in a second, and about 2^31 seconds in about 68 years.

So with a Double, you can span about 4*68 years, in the future of epoch (same in the past), while keeping the microsecond precision.

That seems well enough, considering that second precision for an event several centuries ago is sufficient.

And with the avent of SmallDouble in 64 bits Spur, that would be certainly more efficient than now.

But nanos would cost 10 more bits and be rapidly out of reach (with a span of +/- 3 month around the epoch)...

I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer, but I didn't measure anything...

Nicolas

2014-04-19 4:42 GMT+02:00 David T. Lewis <[hidden email]>:

I have been experimenting with a new implementation of DateAndTime based
on a UTC magnitude. In this implementation, the instance variables jdn,
seconds, and nanos are replaced with a single utcMicroseconds, and the
offset (a Duration) is replaced by localOffsetSeconds (an integer). The
UTC magnitude and offset are provided directly by primitiveUtcWithOffset
when doing DateAndTime now.

I had hoped to achieve a sigificant performance advantage with this
implementation, and while it does improve performance, I am only seeing
about a 10% improvement overall, which is considerably less than I had hoped.
Nevertheless, it is indeed faster, and implemention does have some interesting
characteristics.

The utcMicroseconds magnitude is in units of microseconds, but it is not
required to be an integer and may represent time to any precision. In practice,
values are integral unless the instance is explicitly created with a nanosecond
value.

New instances created by "DateAndTime now" will have the correct time zone
offset as provided by the operating system platform, and their magnitude is
set to a UTC value the precision provided by the platform.

New instances created by other constructors use TimeZone default, which is
problematic given that the time zone in Squeak may or may not match the
(presumably correct) values provided by the operating system.

Instances of DateAndTime are (at the moment) considered equal if their magnitudes
are the same, independent of the time zone offset. This makes sense when thinking
of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances
with different local offsets are equal might be wrong in other contexts.

The localOffsetSeconds is used for displaying the date and time, and is not
related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a
formatter (use the offset to show the magnitude in the context of a local
time zone).

Dave

David T. Lewis

Re: Some DateAndTime experiments

On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
> Hi Dave,
> did you lurk at the work in Pharo?
> I think they followed similar approach, but they kept jdn seconds and
> nanos, representing time in UTC, and they used UTC clock exlcusively.
> It would be interesting to compare the timings vs latest Pharo (3.0).

Hi Nicolas,

Yes, I'm aware of the Pharo work.

The approach that I am trying now is based on my earlier work with the
Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.
In order to make that work with DateAndTime, I use a class called
PointInTime that is a magnitude representing UTC time in seconds. This
makes the time zone table lookups simple, and it makes the conversions
to and from DateAndTime easier to test and to understand.

I always thought that it would be interesting to "eliminate the middle
man" in this scheme by making DateAndTime be clearly based on a UTC time
scale. So that is what I am trying now.

>
> A single variable is interesting for simplifying implementation.
> I wonder about the required precision though...
> There are about 2^20 microseconds in a second, and about 2^31 seconds in
> about 68 years.
> So with a Double, you can span about 4*68 years, in the future of epoch
> (same in the past), while keeping the microsecond precision.
> That seems well enough, considering that second precision for an event
> several centuries ago is sufficient.
> And with the avent of SmallDouble in 64 bits Spur, that would be certainly
> more efficient than now.

Interesting that you should say that. In the PointInTime class, I originally
used Float (double) to represent UTC seconds for exactly the reason you
say. It works well, but I tried some other representations and found that
ScaledDecimal provided the best results overall, with good performance and
very nice charactistics for displaying the UTC seconds in an inspector.

But overall, the best approach seems to be just let it be a Number and
don't worry about it. In actual practice, if the UTC time is represented
in units of microsecond, this results in integer values in all practical
cases. In the rare case of specifying nanosecond precision, you get fractions,
which are reasonably efficient also.

>
> But nanos would cost 10 more bits and be rapidly out of reach (with a span
> of +/- 3 month around the epoch)...
> I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer,
> but I didn't measure anything...

ScaledDecimal turns out be be surprisingly good in performance. Despite
its instance variable names ("fraction"), it actually uses integers when
fractions are not required, so it is quite efficient. If I wanted to
explicitly control the type of number used to represent UTC time, I would
use ScaledDecimal.

Dave

> Nicolas
>
>
>
> 2014-04-19 4:42 GMT+02:00 David T. Lewis <[hidden email]>:
>
> > I have been experimenting with a new implementation of DateAndTime based
> > on a UTC magnitude. In this implementation, the instance variables jdn,
> > seconds, and nanos are replaced with a single utcMicroseconds, and the
> > offset (a Duration) is replaced by localOffsetSeconds (an integer). The
> > UTC magnitude and offset are provided directly by primitiveUtcWithOffset
> > when doing DateAndTime now.
> >
> > I had hoped to achieve a sigificant performance advantage with this
> > implementation, and while it does improve performance, I am only seeing
> > about a 10% improvement overall, which is considerably less than I had
> > hoped.
> > Nevertheless, it is indeed faster, and implemention does have some
> > interesting
> > characteristics.
> >
> > The utcMicroseconds magnitude is in units of microseconds, but it is not
> > required to be an integer and may represent time to any precision. In
> > practice,
> > values are integral unless the instance is explicitly created with a
> > nanosecond
> > value.
> >
> > New instances created by "DateAndTime now" will have the correct time zone
> > offset as provided by the operating system platform, and their magnitude is
> > set to a UTC value the precision provided by the platform.
> >
> > New instances created by other constructors use TimeZone default, which is
> > problematic given that the time zone in Squeak may or may not match the
> > (presumably correct) values provided by the operating system.
> >
> > Instances of DateAndTime are (at the moment) considered equal if their
> > magnitudes
> > are the same, independent of the time zone offset. This makes sense when
> > thinking
> > of them as magnitudes (DateAndTime is a Magnitude), but saying that two
> > instances
> > with different local offsets are equal might be wrong in other contexts.
> >
> > The localOffsetSeconds is used for displaying the date and time, and is not
> > related to magnitude. Thus a DateAndTime is both a magnitude (UTC time)
> > and a
> > formatter (use the offset to show the magnitude in the context of a local
> > time zone).
> >
> > Dave
> >
> >

David T. Lewis

Re: Some DateAndTime experiments

On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:

> On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
> > Hi Dave,
> > did you lurk at the work in Pharo?
> > I think they followed similar approach, but they kept jdn seconds and
> > nanos, representing time in UTC, and they used UTC clock exlcusively.
> > It would be interesting to compare the timings vs latest Pharo (3.0).
>
> Hi Nicolas,
>
> Yes, I'm aware of the Pharo work.
>
> The approach that I am trying now is based on my earlier work with the
> Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.

<OT>
Well, what do you know, it seems that I just got my first link from Wikipedia.
On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there
is a link for "The Squeak Smalltalk time package" that points to the Olson
time zone database for Squeak.
</OT>

Dave

Nicolas Cellier

Re: Some DateAndTime experiments

2014-04-19 15:29 GMT+02:00 David T. Lewis <[hidden email]>:

On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:
> On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
> > Hi Dave,
> > did you lurk at the work in Pharo?
> > I think they followed similar approach, but they kept jdn seconds and
> > nanos, representing time in UTC, and they used UTC clock exlcusively.
> > It would be interesting to compare the timings vs latest Pharo (3.0).
>
> Hi Nicolas,
>
> Yes, I'm aware of the Pharo work.
>
> The approach that I am trying now is based on my earlier work with the
> Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.

<OT>
Well, what do you know, it seems that I just got my first link from Wikipedia.
On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there
is a link for "The Squeak Smalltalk time package" that points to the Olson
time zone database for Squeak.
</OT>

Dave

Congrats for the fame ;)
And thanks for reporting your observations about Integer and Fraction efficiency.

A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can completely change the figures anyway.

Chris Muller-3

Re: open paren/brace/bracket...

In reply to this post by Igor Stasenko

>> It's not about saving keystrokes. It's about automatic closure of
>> multiple nested expressions. Query's like this are almost impossible
>> to "type" without Auto Enclose:
>>
>
> Usually, when this happens, this is a good sign that your code needs
> refactoring.

Yes, that's why I gave the example of an ad-hoc query, because in
practice they're short "throw-away" workspace expressions rather than
factored methods.

>>
>> ^ (cube
>> plot: [ : dim | dim date month ]
>> measures:
>> [ : meas |
>> (meas mean score plotNumber: 1)
>> , ((meas
>> define: #fractionOfWinners
>> as: [ : cell | cell total winnerCount / cell total
>> count ]) plotNumber: 2)
>> , (meas mean gainFactor
>> plotNumber: 3;
>> colorizer: [ : val | val > 0 ifTrue: [Color green
>> twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ]
>> where:
>> [ : cell |
>> (cell dimension date year equalTo: Date today asYear)
>> | (cell dimension date year equalTo: Date today asYear
>> previous) ]) open
>>
>> It'd be much more easily "assembled", expression by expression, but
>> Auto Enclose gives typing it at least a chance of success. :)
>>
>> >> Similarly, deleting an unwanted character is cheap, but deciding
>> >> whether
>> >> to do so is a huge cost.
>> >> I have to stop thinking about what I'm doing, and think ahead to what
>> >> I'm
>> >> going to do next. Even
>> >> if I know I'm going to need the closing character, it stays in my field
>> >> of
>> >> view and takes up cycles
>> >> as a pending thing that I have to worry about until I complete the
>> >> encoded
>> >> expression.
>>
>> So I'm surprised you don't better appreciate the atomicity of
>> expression-editing. Deleting a paren/brace/quote character breaks the
>> code and even breaks the formatter so you can get really stuck on
>> complex expressions. Taking an approach of expression-editing, one is
>> determined not to let the code ever be broken even for a short period
>> of time.
>>
>> >> So, the benefit is small and unreliable, while the cost is large and
>> >> inevitable. It forces me to think
>> >> about typing, which normally I don't have to do. Thus, it's
>> >> infuriating.
>>
>> Yep, I totally get you. But if you ever decide to try committing to
>> Squeak's very capable expression-editing functions, I hope it'll work
>> out as well for you as for me.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>

Eliot Miranda-2

Re: Some DateAndTime experiments

In reply to this post by Nicolas Cellier

On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier <[hidden email]> wrote:

2014-04-19 15:29 GMT+02:00 David T. Lewis <[hidden email]>:

On Sat, Apr 19, 2014 at 09:12:47AM -0400, David T. Lewis wrote:
> On Sat, Apr 19, 2014 at 10:34:04AM +0200, Nicolas Cellier wrote:
> > Hi Dave,
> > did you lurk at the work in Pharo?
> > I think they followed similar approach, but they kept jdn seconds and
> > nanos, representing time in UTC, and they used UTC clock exlcusively.
> > It would be interesting to compare the timings vs latest Pharo (3.0).
>
> Hi Nicolas,
>
> Yes, I'm aware of the Pharo work.
>
> The approach that I am trying now is based on my earlier work with the
> Olson time zone tables in http://www.squeaksource.com/TimeZoneDatabase.

<OT>
Well, what do you know, it seems that I just got my first link from Wikipedia.
On http://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems there
is a link for "The Squeak Smalltalk time package" that points to the Olson
time zone database for Squeak.
</OT>

Dave

Congrats for the fame ;)
And thanks for reporting your observations about Integer and Fraction efficiency.
A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can completely change the figures anyway.

Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal = (2^60) - 1 , which is 36,000 years into the future :-)

DateAndTime fromSeconds: (1 << 60) - 1 // 1000000 38435-08-17T21:30:06-07:00

--
best,

Eliot

David T. Lewis

Re: Some DateAndTime experiments

On Sat, Apr 19, 2014 at 11:44:34AM -0700, Eliot Miranda wrote:

> On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier <
> [hidden email]> wrote:
>
> > A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can
> > completely change the figures anyway.
>
> Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal =
> (2^60) - 1 , which is 36,000 years into the future :-)
>
> DateAndTime fromSeconds: (1 << 60) - 1 // 1000000 38435-08-17T21:30:06-07:00

Ha! Reminds me of the guy who thought 640k was going to be enough ;-)

Dave

Eliot Miranda-2

Re: Some DateAndTime experiments

On Sat, Apr 19, 2014 at 11:50 AM, David T. Lewis <[hidden email]> wrote:

On Sat, Apr 19, 2014 at 11:44:34AM -0700, Eliot Miranda wrote:
> On Sat, Apr 19, 2014 at 9:10 AM, Nicolas Cellier <
> [hidden email]> wrote:
>

> > A 64 bits Spur should also scale our SmallIntegers up to 2^62, which can
> > completely change the figures anyway.
>
> Likely 2^60. 3 bits for tags, 1 bit for sign, hence SmallInteger maxVal =
> (2^60) - 1 , which is 36,000 years into the future :-)
>
> DateAndTime fromSeconds: (1 << 60) - 1 // 1000000 38435-08-17T21:30:06-07:00

Ha! Reminds me of the guy who thought 640k was going to be enough ;-)

Upload your consciousness today ;-)

Paul DeBruicker

Re: Some DateAndTime experiments

In reply to this post by David T. Lewis

You probably looked at this but Chronos, in the unadulterated Squeak 4.4 all-in-one, is ~2.5x faster than DateAndTime. E.g.

[100000 timesRepeat: [Timepoint now]] timeToRun 387

[100000 timesRepeat: [DateAndTime now]] timeToRun 971

Maybe there are some ideas worth taking in there.

The Chronos repo is here:

MCHttpRepository
location: 'http://smalltalkhub.com/mc/Chronos/Chronos/main'
user: ''
password: ''

You can load it in a workspace with

ConfigurationOfChronos load

Assuming you have metacello loaded.

David T. Lewis wrote

I have been experimenting with a new implementation of DateAndTime based
on a UTC magnitude. In this implementation, the instance variables jdn,
seconds, and nanos are replaced with a single utcMicroseconds, and the
offset (a Duration) is replaced by localOffsetSeconds (an integer). The
UTC magnitude and offset are provided directly by primitiveUtcWithOffset
when doing DateAndTime now.

I had hoped to achieve a sigificant performance advantage with this
implementation, and while it does improve performance, I am only seeing
about a 10% improvement overall, which is considerably less than I had hoped.
Nevertheless, it is indeed faster, and implemention does have some interesting
characteristics.

The utcMicroseconds magnitude is in units of microseconds, but it is not
required to be an integer and may represent time to any precision. In practice,
values are integral unless the instance is explicitly created with a nanosecond
value.

New instances created by "DateAndTime now" will have the correct time zone
offset as provided by the operating system platform, and their magnitude is
set to a UTC value the precision provided by the platform.

New instances created by other constructors use TimeZone default, which is
problematic given that the time zone in Squeak may or may not match the
(presumably correct) values provided by the operating system.

Instances of DateAndTime are (at the moment) considered equal if their magnitudes
are the same, independent of the time zone offset. This makes sense when thinking
of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances
with different local offsets are equal might be wrong in other contexts.

The localOffsetSeconds is used for displaying the date and time, and is not
related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a
formatter (use the offset to show the magnitude in the context of a local
time zone).

Dave

David T. Lewis

Re: Some DateAndTime experiments

On Sat, Apr 19, 2014 at 01:31:43PM -0700, Paul DeBruicker wrote:
> You probably looked at this but Chronos, in the unadulterated Squeak 4.4
> all-in-one, is ~2.5x faster than DateAndTime. E.g.
>
> [100000 timesRepeat: [Timepoint now]] timeToRun 387
>
> [100000 timesRepeat: [DateAndTime now]] timeToRun 971
>

Actually, this is one area where the experimental DateAndTime version
gives a substantial improvement.

Squeak trunk:
[1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 2448

Modified version with UTC based DateAndTime:
[1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 1264

But it turns out that most uses of DateAndTime involve conversion to and
from strings, so in practice most the time time gets eaten up in parsing
and in numeric conversions, regardless of the underlyingkrepresentation
of the time magnitude.

The single UTC variable approach has some advantage in overall simplicity,
but that seems to be partly offset by efficiencies of small integer
computation in the current DateAndTime approach.

Dave

>
> Maybe there are some ideas worth taking in there.
>
>
>
> The Chronos repo is here:
>
> MCHttpRepository
> location: 'http://smalltalkhub.com/mc/Chronos/Chronos/main'
> user: ''
> password: ''
>
> You can load it in a workspace with
>
> ConfigurationOfChronos load
>
>
> Assuming you have metacello loaded.
>
>
>
>
>
>
>
> David T. Lewis wrote
> > I have been experimenting with a new implementation of DateAndTime based
> > on a UTC magnitude. In this implementation, the instance variables jdn,
> > seconds, and nanos are replaced with a single utcMicroseconds, and the
> > offset (a Duration) is replaced by localOffsetSeconds (an integer). The
> > UTC magnitude and offset are provided directly by primitiveUtcWithOffset
> > when doing DateAndTime now.
> >
> > I had hoped to achieve a sigificant performance advantage with this
> > implementation, and while it does improve performance, I am only seeing
> > about a 10% improvement overall, which is considerably less than I had
> > hoped.
> > Nevertheless, it is indeed faster, and implemention does have some
> > interesting
> > characteristics.
> >
> > The utcMicroseconds magnitude is in units of microseconds, but it is not
> > required to be an integer and may represent time to any precision. In
> > practice,
> > values are integral unless the instance is explicitly created with a
> > nanosecond
> > value.
> >
> > New instances created by "DateAndTime now" will have the correct time zone
> > offset as provided by the operating system platform, and their magnitude
> > is
> > set to a UTC value the precision provided by the platform.
> >
> > New instances created by other constructors use TimeZone default, which is
> > problematic given that the time zone in Squeak may or may not match the
> > (presumably correct) values provided by the operating system.
> >
> > Instances of DateAndTime are (at the moment) considered equal if their
> > magnitudes
> > are the same, independent of the time zone offset. This makes sense when
> > thinking
> > of them as magnitudes (DateAndTime is a Magnitude), but saying that two
> > instances
> > with different local offsets are equal might be wrong in other contexts.
> >
> > The localOffsetSeconds is used for displaying the date and time, and is
> > not
> > related to magnitude. Thus a DateAndTime is both a magnitude (UTC time)
> > and a
> > formatter (use the offset to show the magnitude in the context of a local
> > time zone).
> >
> > Dave
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/open-paren-brace-bracket-tp4755162p4755475.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.