[squeak-dev] About the new Date

David T. Lewis lewis at mail.msen.com
Sun Feb 5 17:02:02 UTC 2012


On Sat, Feb 04, 2012 at 11:57:51AM -0500, Jon Hylands wrote:
> On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
> > I'm struggling to understand why "Date today" should be a TimeSpan that
> > begins at some time other than midnight in my local time zone. The date
> > that I think of as "4 February 2012" began about 20 minutes ago here in
> > Detroit, but in London and Paris it is old news.
> >
> 
> David,
> 
> The issue that I'm having is this:
> 
> When I evaluate and store this object today: (Date newDay: 1 month: 1 year:
> 2012), and then six months later I evaluate exactly the same expression,
> because I live in a country where daylight savings is applied, those two
> objects will not be equal.
> 
> I can't think of a single logical reason why it should work that way. When
> I create a date (any date), it sets the timezone of the date to be whatever
> current timezone I happen to be in. That makes Date completely unusable as
> a historical indexing object.
> 
> - Jon

In thinking about this problem from the point of view of the problems of
performance (Date>>hash) and time zone inconsistencies that Chris has been
describing, it strikes me that a possible solution for those issues would
be to have a type of date (call it "DateStamp") for which the equality
test depends only the the julian date number associated with that date.
The behavior would be like that of the old Date class that existed in
Squeak prior to Chronology, where the hashing and comparison is based on
a single SmallInteger value (julianDayNumber), hence fast and independent
of time zone. Subclassing Date is not exactly elegant, but it's certainly
simple and it might provide a practical way to address these problems
without too many surprises for existing users of the Date class.

I am not necessarily suggesting this for inclusion in the image, just
offering it as a suggestion that might provide an easy way to address
the performance and consistency issues.

Change set attached.

Dave

-------------- next part --------------
'From Squeak3.11alpha of 2 February 2012 [latest update: #11890] on 5 February 2012 at 11:35:32 am'!
"Change Set:		DateStamp-dtl
Date:			5 February 2012
Author:			David T. Lewis

A DateStamp represents a calendar day, independent of time zone. DateStamp is optimized for fast comparison, where two date stamps are considered equal if they have the same start time.

DateStamp is similar to the Date class that was implemented in Squeak prior to introduction of Chronology (see a Squeak 3.6 for reference) in that the julianDayNumber of the date stamp is its only basis for comparison of two instances."!

Date subclass: #DateStamp
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-Chronology'!

!DateStamp commentStamp: 'dtl 2/5/2012 09:58' prior: 0!
A DateStamp represents a calendar day, independent of time zone. DateStamp is optimized for fast comparison, where two date stamps are considered equal if they have the same start time.
!


!DateAndTime methodsFor: 'squeak protocol' stamp: 'dtl 2/5/2012 09:53'!
asDateStamp


	^ DateStamp starting: self asDateAndTime! !


!String methodsFor: 'converting' stamp: 'dtl 2/5/2012 09:53'!
asDateStamp
	"Many allowed forms, see Date>>#readFrom:"

	^ DateStamp fromString: self! !


!Time methodsFor: 'squeak protocol' stamp: 'dtl 2/5/2012 09:53'!
asDateStamp

	^ DateStamp today! !


!Timespan methodsFor: 'squeak protocol' stamp: 'dtl 2/5/2012 09:54'!
asDate


	^ start asDateStamp! !


!Date methodsFor: 'squeak protocol' stamp: 'dtl 2/5/2012 09:52'!
asDateStamp

	^ DateStamp newFrom: self
! !


!DateStamp methodsFor: 'comparing' stamp: 'dtl 2/5/2012 09:43'!
= aDate

	^start julianDayNumber = aDate start julianDayNumber! !

!DateStamp methodsFor: 'comparing' stamp: 'dtl 2/5/2012 09:44'!
hash

	^start julianDayNumber hash! !



More information about the Squeak-dev mailing list