On Fri, Jul 02, 2004 at 10:45:04PM -0700, Ross Boylan wrote:
> The following change to DateAndTime>>< makes a noticeable difference
> in speed for me.  Note that the version of DateAndTime I'm working
> with is not quite the same as the current one; I don't know if this
> method has changed.
> 
> In words, I check if the offsets are the same, and if so, skip the
> asUTC conversion, which is the expensive part of the operation.

This is risky, since the same point in UTC can have different
representations in terms of day/seconds/nanos, with one category
overflowing into the next (I think).

This, like the offset issue just below, points to the potential
benefits of storing the information in a normalized form.  I do not
believe this is guaranteed at the moment.

While I think the optimization will work for me, it is probably not
sufficiently robust for general use.

> 
> Shifts in daylight savings time could cause the expensive branch to
> kick in.  Probably the internal time should always be stored as UTC,
> with the offset used just for display purposes.
> 
> < comparand
> 
> 	| lutc rutc rhs|
> 	rhs _ comparand asDateAndTime.
> 	self offset == rhs offset ifTrue: [
> 		lutc _ self utc.
> 		rutc _ rhs utc.
> 	] ifFalse: 
> 	[
> 	lutc _ self asUTC utc.
> 	rutc _ rhs asUTC utc.
> 	].
> 	^lutc first < rutc first
> 	ifTrue: [ true ]
> 	ifFalse: 
> 	[
> 		lutc first > rutc first
> 		ifTrue: [ false ] 
> 		ifFalse: 
> 		[
> 			lutc second < rutc second
> 			ifTrue: [ true ] 
> 			ifFalse: 
> 			[
> 				lutc second > rutc second
> 				ifTrue: [ false ]
> 				ifFalse: 
> 				[
> 					lutc third < rutc third
> 				]
> 			]
> 		]
> 	]
> 
> 
> I know this isn't a proper change set, or fileout, but my fileout from
> the dual change sorter seems to be broken.
> 
>