What's up on build.squeak.org

> On 25.05.2014, at 19:48, David T. Lewis <[hidden email]> wrote:
>
> > Performance of the UTC based DateAndTime is generally favorable compared to
> > the original. Here is what I see on my system (smaller numbers are better).
> >
> > LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
> > on an interpreter VM:
> > {
> > #testNow->10143 .
> > #testEquals->30986 .
> > #testGreaterThan->80199 .
> > #testLessThan->75912 .
> > #testPrintString->10429 .
> > #testStringAsDateAndTime->44657
> > }
> >
> > LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
> > on an interpreter VM:
> > {
> > #testNow->6423 .
> > #testEquals->31625 .
> > #testGreaterThan->22999 .
> > #testLessThan->18514 .
> > #testPrintString->12502 .
> > #testStringAsDateAndTime->32912
> > }
>
> Hi Dave,
>
> just curious: did you test the performance without the LargeInt primitives?
>
> - Bert -
>

>
> On 25.05.2014, at 22:43, Nicolas Cellier <[hidden email]> wrote:
>
>>
>> 2014-05-25 18:34 GMT+02:00 Nicolas Cellier <[hidden email]>:
>>
>> 2014-05-25 2:39 GMT+02:00 Chris Muller <[hidden email]>:
>>
>> Hi, thanks for noticing and investigating this!  Seeing this now, I
>> think we should signal an Error rather than a Warning to be more
>> TestCase friendly but also because persisting empty packages is so
>> painful, it should be an error, hands down.  Better to force a
>> resolution to the issue than silently persist modules of
>> future-pain...
>>
>>
>> In any case, I think you accidently uncovered bugs in Tests-Monticello.
>> I'm looking at a fix for a few hours, and it's really messy.
>>
>>
>> Hooray! After publishing Tests-nice.297 there is now a trunk CI job that finished
>> http://build.squeak.org/job/SqueakTrunk/857/
>>
>> Now we can see we have some regressions...
>> How could we live without CI before?
>>
>> Of course, for dissecting which change introduced which regression after a 2 month interrupt, that's going to be more pain than necessary...
>>
>
> To not make that happen again, can we make the jenkins mail squeak-dev on
> important (read me, not all) information?
> Like:
>         more tests fail
>         errors
>         (possibly one nightly information)

> On 25 May 2014 21:52, Tobias Pape <[hidden email]> wrote:
>>
>> On 25.05.2014, at 22:43, Nicolas Cellier <[hidden email]> wrote:
>>
>>>
>>> 2014-05-25 18:34 GMT+02:00 Nicolas Cellier <[hidden email]>:
>>>
>>> 2014-05-25 2:39 GMT+02:00 Chris Muller <[hidden email]>:
>>>
>>> Hi, thanks for noticing and investigating this!  Seeing this now, I
>>> think we should signal an Error rather than a Warning to be more
>>> TestCase friendly but also because persisting empty packages is so
>>> painful, it should be an error, hands down.  Better to force a
>>> resolution to the issue than silently persist modules of
>>> future-pain...
>>>
>>>
>>> In any case, I think you accidently uncovered bugs in Tests-Monticello.
>>> I'm looking at a fix for a few hours, and it's really messy.
>>>
>>>
>>> Hooray! After publishing Tests-nice.297 there is now a trunk CI job that finished
>>> http://build.squeak.org/job/SqueakTrunk/857/
>>>
>>> Now we can see we have some regressions...
>>> How could we live without CI before?
>>>
>>> Of course, for dissecting which change introduced which regression after a 2 month interrupt, that's going to be more pain than necessary...
>>>
>>
>> To not make that happen again, can we make the jenkins mail squeak-dev on
>> important (read me, not all) information?
>> Like:
>>         more tests fail
>>         errors
>>         (possibly one nightly information)
>
> We possibly could, but I'd suggest _not_ doing so because even without
> Nicolas's work (thanks very much, Nicolas!) we _normally_ have failing
> tests, which means that the normal status of the SqueakTrunk build
> would not be green.
>
> Really, the ideal place to be is for the job to usually be green,
> because then CI saying anything at all is cause for alarm, not yet
> another false positive. And we're just not there, on a number of
> fronts.

> On Wed, May 28, 2014 at 11:49:08AM +0200, Bert Freudenberg wrote:
> > On 25.05.2014, at 19:48, David T. Lewis <[hidden email]> wrote:
> >
> > > Performance of the UTC based DateAndTime is generally favorable compared to
> > > the original. Here is what I see on my system (smaller numbers are better).
> > >
> > > LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
> > > on an interpreter VM:
> > > {
> > > #testNow->10143 .
> > > #testEquals->30986 .
> > > #testGreaterThan->80199 .
> > > #testLessThan->75912 .
> > > #testPrintString->10429 .
> > > #testStringAsDateAndTime->44657
> > > }
> > >
> > > LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
> > > on an interpreter VM:
> > > {
> > > #testNow->6423 .
> > > #testEquals->31625 .
> > > #testGreaterThan->22999 .
> > > #testLessThan->18514 .
> > > #testPrintString->12502 .
> > > #testStringAsDateAndTime->32912
> > > }
> >
> > Hi Dave,
> >
> > just curious: did you test the performance without the LargeInt primitives?
> >
> > - Bert -
> >
>
> For the new UTC implementation with the primitive disabled, fallback code is
> much slower for DateAndTime class>>now.
>
> {
> #testNow->36939 .
> #testEquals->29015 .
> #testGreaterThan->21142 .
> #testLessThan->17586 .
> #testPrintString->11809 .
> #testStringAsDateAndTime->30918
> }
>

> On Tue, May 27, 2014 at 09:55:33PM +0200, Nicolas Cellier wrote:
>> 2014-05-27 4:30 GMT+02:00 Chris Muller <[hidden email]>:
>>
>>> The issue actually relates purely to Squeak domain models.  Consider
>>> the case of an all-in-memory object model in Squeak, with no database
>>> involved at all.  It is very feasible an app would want to import a
>>> flat-file dataset that involves creation a few million DateAndTime
>>> instances (along with other objects, of course) to the point where
>>> memory constraints begin to be noticed.
>>>
>>> When dealing with this level of prolifigation-potential of a
>>> particular class, and for such a base data-type we don't want to
>>> endure changing again, I want us to strongly scrutinize the internal
>>> representation.
>>>
>>> In this case, the use of 'utcMicroseconds' introduces a lot of
>>> duplicate bit-patterns in memory that are very hard, if not
>>> impossible, to share.
>>>
>>> The simplest case are two equivalent instances of DateAndTime (read
>>> from separate files).  Despite being equivalent, their
>>> utcMicroseconds' will be separate objects each consuming separate
>>> memory space.  There is no easy way to share the same
>>> 'utcMicroseconds' instance between them.
>>>
>>> But fully-equivalent DateAndTime's is not even half of the concern --
>>> the high-order bits of every DateAndTime's 'utcMicroseconds'
>>> duplicates the same bit pattern, again and again, eating up memory.
>>>
>>> That doesn't happen when the internal representations are, or can be,
>>> canonicalized, as in the case of using SmallIntegers.  Yes, Brent's
>>> original representation requires two additional slots per instance,
>>> but the _contents_ of those slots are SmallIntegers -- shared memory.
>>>
>>>
>> Well, in current 32 bit image format, SmallInteger are not exactly shared,
>> they are immediate values.
>> Each consumes exactly 32 bits.
>>
>> For a compact class like LargePosOrNegInteger, I don't remember what is the
>> header size exactly, but you get 64 bits for data, I would be surprised to
>> see a major difference wrt consumed memory.
>>
>
> Smalltalk compactClassesArray includes: DateAndTime ==> false
> Smalltalk compactClassesArray includes: LargePositiveInteger ==> true
>
> So for the traditional DateAndTime implementation, an instance requires:
>
>  2 words of header (64 bits)
>  3 words for the small integer jdn/seconds/nanos variables
>  1 word for the pointer to the offset object, which is an instance of Duration
>
> In practice, most instances of DateAndTime within an image will share the
> same offset object, so for purposes of estimation assume that this takes
> no extra space.
>
> Thus each instance requires 6 words of space in the object memory (maybe a bit
> more on average if the DateAndTime instances are not sharing the same Duration
> instance for one reason or another).
>
> For the UTC based implementation of DateAndTime, each instance requires:
>
>  2 words of header
>  1 word for the small integer localOffsetSeconds variable
>  1 word for the pointer to the LargePositiveInteger representing utcMicroSeconds
>  1 word of header for the large positive integer
>  2 words of data for the value of the large positive integer
>
> Thus each instance requires 7 words of space in the object memory.
>
> So there is a difference, but it would probably not be a large effect on
> overall space utilization, even assuming complete sharing of the offset
> Duration instances.

> On Tue, 27 May 2014, David T. Lewis wrote:
>
>> On Tue, May 27, 2014 at 09:55:33PM +0200, Nicolas Cellier wrote:
>>>
>>> 2014-05-27 4:30 GMT+02:00 Chris Muller <[hidden email]>:
>>>
>>>> The issue actually relates purely to Squeak domain models.  Consider
>>>> the case of an all-in-memory object model in Squeak, with no database
>>>> involved at all.  It is very feasible an app would want to import a
>>>> flat-file dataset that involves creation a few million DateAndTime
>>>> instances (along with other objects, of course) to the point where
>>>> memory constraints begin to be noticed.
>>>>
>>>> When dealing with this level of prolifigation-potential of a
>>>> particular class, and for such a base data-type we don't want to
>>>> endure changing again, I want us to strongly scrutinize the internal
>>>> representation.
>>>>
>>>> In this case, the use of 'utcMicroseconds' introduces a lot of
>>>> duplicate bit-patterns in memory that are very hard, if not
>>>> impossible, to share.
>>>>
>>>> The simplest case are two equivalent instances of DateAndTime (read
>>>> from separate files).  Despite being equivalent, their
>>>> utcMicroseconds' will be separate objects each consuming separate
>>>> memory space.  There is no easy way to share the same
>>>> 'utcMicroseconds' instance between them.
>>>>
>>>> But fully-equivalent DateAndTime's is not even half of the concern --
>>>> the high-order bits of every DateAndTime's 'utcMicroseconds'
>>>> duplicates the same bit pattern, again and again, eating up memory.
>>>>
>>>> That doesn't happen when the internal representations are, or can be,
>>>> canonicalized, as in the case of using SmallIntegers.  Yes, Brent's
>>>> original representation requires two additional slots per instance,
>>>> but the _contents_ of those slots are SmallIntegers -- shared memory.
>>>>
>>>>
>>> Well, in current 32 bit image format, SmallInteger are not exactly
>>> shared,
>>> they are immediate values.
>>> Each consumes exactly 32 bits.
>>>
>>> For a compact class like LargePosOrNegInteger, I don't remember what is
>>> the
>>> header size exactly, but you get 64 bits for data, I would be surprised
>>> to
>>> see a major difference wrt consumed memory.
>>>
>>
>> Smalltalk compactClassesArray includes: DateAndTime ==> false
>> Smalltalk compactClassesArray includes: LargePositiveInteger ==> true
>>
>> So for the traditional DateAndTime implementation, an instance requires:
>>
>>  2 words of header (64 bits)
>>  3 words for the small integer jdn/seconds/nanos variables
>>  1 word for the pointer to the offset object, which is an instance of
>> Duration
>>
>> In practice, most instances of DateAndTime within an image will share the
>> same offset object, so for purposes of estimation assume that this takes
>> no extra space.
>>
>> Thus each instance requires 6 words of space in the object memory (maybe a
>> bit
>> more on average if the DateAndTime instances are not sharing the same
>> Duration
>> instance for one reason or another).
>>
>> For the UTC based implementation of DateAndTime, each instance requires:
>>
>>  2 words of header
>>  1 word for the small integer localOffsetSeconds variable
>>  1 word for the pointer to the LargePositiveInteger representing
>> utcMicroSeconds
>>  1 word of header for the large positive integer
>>  2 words of data for the value of the large positive integer
>>
>> Thus each instance requires 7 words of space in the object memory.
>>
>> So there is a difference, but it would probably not be a large effect on
>> overall space utilization, even assuming complete sharing of the offset
>> Duration instances.
>
>
> I think it's possible to reduce the number of words to 5 at the cost of
> reusing integer primitives. If DateAndTime is a variable byte class, then it
> can hold the utcMicroSeconds in 8 variable slots (2 words). I don't know if
> the LargeInteger primitives would work with it, but I think they should, so
> comparison and arithmetic methods could be based on them.
>
> But it's probably not worth to care about this, because Spur will change
> these things.
>
>
> Levente
>
>>
>> Dave
>>
>>
>>
>

> The more and higher-level parts a DateAndTime can be constructed with,
> the better the opportunity for memory-optimization.  Conversely, the
> more an implementation moves more toward a 'binary data'
> representation, the fewer of those bits can be shared and, therefore,
> the more that will be duplicated across instances.
>
> On Mon, Jun 2, 2014 at 2:21 PM, Levente Uzonyi <[hidden email]> wrote:
>> On Tue, 27 May 2014, David T. Lewis wrote:
>>
>>> On Tue, May 27, 2014 at 09:55:33PM +0200, Nicolas Cellier wrote:
>>>>
>>>> 2014-05-27 4:30 GMT+02:00 Chris Muller <[hidden email]>:
>>>>
>>>>> The issue actually relates purely to Squeak domain models.  Consider
>>>>> the case of an all-in-memory object model in Squeak, with no database
>>>>> involved at all.  It is very feasible an app would want to import a
>>>>> flat-file dataset that involves creation a few million DateAndTime
>>>>> instances (along with other objects, of course) to the point where
>>>>> memory constraints begin to be noticed.
>>>>>
>>>>> When dealing with this level of prolifigation-potential of a
>>>>> particular class, and for such a base data-type we don't want to
>>>>> endure changing again, I want us to strongly scrutinize the internal
>>>>> representation.
>>>>>
>>>>> In this case, the use of 'utcMicroseconds' introduces a lot of
>>>>> duplicate bit-patterns in memory that are very hard, if not
>>>>> impossible, to share.
>>>>>
>>>>> The simplest case are two equivalent instances of DateAndTime (read
>>>>> from separate files).  Despite being equivalent, their
>>>>> utcMicroseconds' will be separate objects each consuming separate
>>>>> memory space.  There is no easy way to share the same
>>>>> 'utcMicroseconds' instance between them.
>>>>>
>>>>> But fully-equivalent DateAndTime's is not even half of the concern --
>>>>> the high-order bits of every DateAndTime's 'utcMicroseconds'
>>>>> duplicates the same bit pattern, again and again, eating up memory.
>>>>>
>>>>> That doesn't happen when the internal representations are, or can be,
>>>>> canonicalized, as in the case of using SmallIntegers.  Yes, Brent's
>>>>> original representation requires two additional slots per instance,
>>>>> but the _contents_ of those slots are SmallIntegers -- shared memory.
>>>>>
>>>>>
>>>> Well, in current 32 bit image format, SmallInteger are not exactly
>>>> shared,
>>>> they are immediate values.
>>>> Each consumes exactly 32 bits.
>>>>
>>>> For a compact class like LargePosOrNegInteger, I don't remember what is
>>>> the
>>>> header size exactly, but you get 64 bits for data, I would be surprised
>>>> to
>>>> see a major difference wrt consumed memory.
>>>>
>>>
>>> Smalltalk compactClassesArray includes: DateAndTime ==> false
>>> Smalltalk compactClassesArray includes: LargePositiveInteger ==> true
>>>
>>> So for the traditional DateAndTime implementation, an instance requires:
>>>
>>>  2 words of header (64 bits)
>>>  3 words for the small integer jdn/seconds/nanos variables
>>>  1 word for the pointer to the offset object, which is an instance of
>>> Duration
>>>
>>> In practice, most instances of DateAndTime within an image will share the
>>> same offset object, so for purposes of estimation assume that this takes
>>> no extra space.
>>>
>>> Thus each instance requires 6 words of space in the object memory (maybe a
>>> bit
>>> more on average if the DateAndTime instances are not sharing the same
>>> Duration
>>> instance for one reason or another).
>>>
>>> For the UTC based implementation of DateAndTime, each instance requires:
>>>
>>>  2 words of header
>>>  1 word for the small integer localOffsetSeconds variable
>>>  1 word for the pointer to the LargePositiveInteger representing
>>> utcMicroSeconds
>>>  1 word of header for the large positive integer
>>>  2 words of data for the value of the large positive integer
>>>
>>> Thus each instance requires 7 words of space in the object memory.
>>>
>>> So there is a difference, but it would probably not be a large effect on
>>> overall space utilization, even assuming complete sharing of the offset
>>> Duration instances.
>>
>>
>> I think it's possible to reduce the number of words to 5 at the cost of
>> reusing integer primitives. If DateAndTime is a variable byte class, then it
>> can hold the utcMicroSeconds in 8 variable slots (2 words). I don't know if
>> the LargeInteger primitives would work with it, but I think they should, so
>> comparison and arithmetic methods could be based on them.
>>
>> But it's probably not worth to care about this, because Spur will change
>> these things.
>>
>>
>> Levente
>>
>>>
>>> Dave
>>>
>>>
>>>
>>

> On Tue, 27 May 2014, David T. Lewis wrote:
>
> >On Tue, May 27, 2014 at 09:55:33PM +0200, Nicolas Cellier wrote:
> >>2014-05-27 4:30 GMT+02:00 Chris Muller <[hidden email]>:
> >>
> >>>The issue actually relates purely to Squeak domain models.  Consider
> >>>the case of an all-in-memory object model in Squeak, with no database
> >>>involved at all.  It is very feasible an app would want to import a
> >>>flat-file dataset that involves creation a few million DateAndTime
> >>>instances (along with other objects, of course) to the point where
> >>>memory constraints begin to be noticed.
> >>>
> >>>When dealing with this level of prolifigation-potential of a
> >>>particular class, and for such a base data-type we don't want to
> >>>endure changing again, I want us to strongly scrutinize the internal
> >>>representation.
> >>>
> >>>In this case, the use of 'utcMicroseconds' introduces a lot of
> >>>duplicate bit-patterns in memory that are very hard, if not
> >>>impossible, to share.
> >>>
> >>>The simplest case are two equivalent instances of DateAndTime (read
> >>>from separate files).  Despite being equivalent, their
> >>>utcMicroseconds' will be separate objects each consuming separate
> >>>memory space.  There is no easy way to share the same
> >>>'utcMicroseconds' instance between them.
> >>>
> >>>But fully-equivalent DateAndTime's is not even half of the concern --
> >>>the high-order bits of every DateAndTime's 'utcMicroseconds'
> >>>duplicates the same bit pattern, again and again, eating up memory.
> >>>
> >>>That doesn't happen when the internal representations are, or can be,
> >>>canonicalized, as in the case of using SmallIntegers.  Yes, Brent's
> >>>original representation requires two additional slots per instance,
> >>>but the _contents_ of those slots are SmallIntegers -- shared memory.
> >>>
> >>>
> >>Well, in current 32 bit image format, SmallInteger are not exactly shared,
> >>they are immediate values.
> >>Each consumes exactly 32 bits.
> >>
> >>For a compact class like LargePosOrNegInteger, I don't remember what is
> >>the
> >>header size exactly, but you get 64 bits for data, I would be surprised to
> >>see a major difference wrt consumed memory.
> >>
> >
> >Smalltalk compactClassesArray includes: DateAndTime ==> false
> >Smalltalk compactClassesArray includes: LargePositiveInteger ==> true
> >
> >So for the traditional DateAndTime implementation, an instance requires:
> >
> > 2 words of header (64 bits)
> > 3 words for the small integer jdn/seconds/nanos variables
> > 1 word for the pointer to the offset object, which is an instance of
> > Duration
> >
> >In practice, most instances of DateAndTime within an image will share the
> >same offset object, so for purposes of estimation assume that this takes
> >no extra space.
> >
> >Thus each instance requires 6 words of space in the object memory (maybe a
> >bit
> >more on average if the DateAndTime instances are not sharing the same
> >Duration
> >instance for one reason or another).
> >
> >For the UTC based implementation of DateAndTime, each instance requires:
> >
> > 2 words of header
> > 1 word for the small integer localOffsetSeconds variable
> > 1 word for the pointer to the LargePositiveInteger representing
> > utcMicroSeconds
> > 1 word of header for the large positive integer
> > 2 words of data for the value of the large positive integer
> >
> >Thus each instance requires 7 words of space in the object memory.
> >
> >So there is a difference, but it would probably not be a large effect on
> >overall space utilization, even assuming complete sharing of the offset
> >Duration instances.
>
> I think it's possible to reduce the number of words to 5 at the cost of
> reusing integer primitives. If DateAndTime is a variable byte class, then
> it can hold the utcMicroSeconds in 8 variable slots (2 words). I don't
> know if the LargeInteger primitives would work with it, but I think they
> should, so comparison and arithmetic methods could be based on them.
>

>
> There are several advantages to this representation of DateAndTime, the most
> important of which is that its magnitude is unambiguous regardless of daylight
> savings transitions in local time zones.
>
> This is my attempt to address some historical baggage in Squeak. The VM
> reports time related to the local time zone, and the image attempts to
> convert to UTC (sometimes incorrectly). A UTC based representation makes the
> implementation of time zone tables more straightforward (see for example
> the Olson time zone tables in TimeZoneDatabase on SqueakMap).
>
> I am attaching the source code as a SAR file that can be loaded into a fully
> updated Squeak trunk image. The conversion process is slow, so be patient
> if you load it.
>
> This can be run on either an intepreter VM or Cog, but if you use Cog, please
> use a version dated June 2013 or later (the VM in the Squeak 4.5 all-in-one
> is fine).
>
> I am also attaching a copy of LXTestDateAndTimePerformance, which can be
> used to compare the performance of some basic DateAndTime functions.
>
> Performance of the UTC based DateAndTime is generally favorable compared to
> the original. Here is what I see on my system (smaller numbers are better).
>
> LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
> on an interpreter VM:
> {
> #testNow->10143 .
> #testEquals->30986 .
> #testGreaterThan->80199 .
> #testLessThan->75912 .
> #testPrintString->10429 .
> #testStringAsDateAndTime->44657
> }
>
> LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
> on an interpreter VM:
> {
> #testNow->6423 .
> #testEquals->31625 .
> #testGreaterThan->22999 .
> #testLessThan->18514 .
> #testPrintString->12502 .
> #testStringAsDateAndTime->32912
> }
>
> (CC to Brent Pinkney, author of the excellent Squeak Chronology package)
>
> Dave
>

> On 25.05.2014, at 19:48, David T. Lewis <[hidden email]> wrote:
>
> > Performance of the UTC based DateAndTime is generally favorable compared to
> > the original. Here is what I see on my system (smaller numbers are better).
> >
> > LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
> > on an interpreter VM:
> > {
> > #testNow->10143 .
> > #testEquals->30986 .
> > #testGreaterThan->80199 .
> > #testLessThan->75912 .
> > #testPrintString->10429 .
> > #testStringAsDateAndTime->44657
> > }
> >
> > LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
> > on an interpreter VM:
> > {
> > #testNow->6423 .
> > #testEquals->31625 .
> > #testGreaterThan->22999 .
> > #testLessThan->18514 .
> > #testPrintString->12502 .
> > #testStringAsDateAndTime->32912
> > }
>
> Hi Dave,
>
> just curious: did you test the performance without the LargeInt primitives?
>
> - Bert -
>

> David T. Lewis wrote
> > the two main responsibilities of DateAndTime. One is
> > to represent time as a magnitude (for duration calculation, etc). The
> > other
> > is to display time in the frame of reference of a local time zone. It is
> > not
> > at all clear to me that those two responsibilies belong in the same class.
>
> There is definitely something fishy with the combination. Consider Pharo's
> Date, which retroactively applies the current timezone to dates. This is bad
> because e.g.:
>   '7/10/2014' asDate "evaluated the day before DST" ~= '7/10/2014' asDate
> "evaluated the day after DST"
>
> I created an issue, which has been sitting on the bug tracker. Here's an
> excerpt from the discussion
> (https://pharo.fogbugz.com/default.asp?12147#BugEvent.90264):
>
> > I see that a particular location could reasonably be implied in a Date,
> > e.g. if we're saying that a treaty was signed on such and such a date, we
> > mean at the place where it was signed... it may have already been the next
> > day in another time zone.
> >
> > Now, what is beyond doubt, is that the timezone that would be implied is
> > the timezone of the date itself, not an artifact of when the instance was
> > created. In my example, I create '11/12/2013' asDate, and it assumes my
> > timezone.
> > Since it's the summer in NY, that means -4 offset. Now, I evaluate
> > '11/12/2013' asDate again in December. Again it implies my timezone, the
> > offset of which has changed to -5! So now '11/12/2013' asDate (in NY) ~=
> > '11/12/2013' asDate (in NY). Even though the offset of the date in
> > question, which depends only on whether DST was in effect on 11/12/2013,
> > has not changed.
> >
> > So the current behavior of two equal dates being considered not-equal is
> > as jarring as your counter example of two non-equal dates (different
> > timezone) being considered equal.