[GemStone-Smalltalk] DateAndTime users' questionnaire

[Paul DeBruicker]

Hi Mang,

In the Java program, with the integer representation,  how did you handle
Daylight savings transitions when doing comparisons or instantiating
objects? 


Thanks

Paul


Gemstone/S mailing list wrote
> I was working on a Shipping operation application called IRIS2 long time
> ago.  We canonicalized the DataTime to reduce the number of instances
> created that represent the same time.  Our resolution is 1 minute to
> reduce the number of instances we need to create.
> Recently, while working on a Java application we also need DateTime, we
> represented DateTime using the format YYYYMMDDHHMMSS.mmm.  This format can
> be represented as an Integer (64bit) in GemStone.  In GemStone, if I
> remember correctly it does not create a new object but embedded 64 bit
> Integer in the object pointer.  So no extra space taken.  And you can
> implement getter and setter that can dynamically return a transient
> DateTime object.  I used this technique in Java because we cached a lot of
> objects in the VM.  This will save a lot of memory space.
> This YYYYMMDDHHMMSS.mmm representation is much more readable but at a cost
> of converting when you need to print them.
> Mang
>     On Friday, June 19, 2020, 06:37:06 PM PDT, Paul Baumann via
> GemStone-Smalltalk <

> gemstone-smalltalk at .gemtalksystems

> > wrote:  
>  
>  I'm excited for this change, it will make a huge performance difference
> having dates as immediates.
> I had done this in tuning in application code where most beneficial. It
> would persist an immediate integer that was seconds, ms, or ns from an
> epoch datetime. Replication to gbs was then a very efficiently of course
> as cache costs were skipped. The slot contained the integer and accessor
> methods made it look like a datetime was stored. The accessor methods used
> DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch:
> #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer
> and DateTime instances according to the epoch and granularity the
> accessors had consistently specified for the slot in both objectspaces
> (gbs and gs). This allowed for incremental application tuning and epoch
> control most efficient for the attribute needs.
> 
> The epoch that I selected for most slots was probably 1/1/2000, but it
> might have also been more recent if the attribute didn't need older dates
> stored efficiently. Sorry, I don't recall what epoch and granularity was
> generally most useful for most attributes. If polymorphism can be assumed
> then you might as well pick an epoch in the near future and dates forward
> will become more efficient.
> Paul Baumann
> 
> 
> On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk <

> gemstone-smalltalk at .gemtalksystems

> > wrote:
> 
> If you use DateAndTime in your GemStone application, we at GemTalk would 
> very much appreciate your feedback on the questions below.
> 
> At customer request, we're working on a SmallDateAndTime class for 
> GemStone -- a "Special" (immediate) version of DateAndTime that relates 
> to DateAndTime similarly to the relationship between SmallInteger and 
> LargeInteger. For customers with many persistent DateAndTime instances, 
> this should improve both space and time performance.
> 
> There are design tradeoffs in resolution, range, printing, etc., and it 
> will help us make better decisions if we know how DateAndTime is being 
> used now.
> 
> (1) Which of the following messages do you use to create DateAndTime 
> instances?
>   * DateAndTime now
>   * DateAndTime nowWithScale:
>   * DateAndTime fromString:
>   * DateAndTime year:day:hour* or year:month:day:hour*
>   * Other protocol
> 
> (2) Do you need DateAndTimes with resolution finer than a microsecond?
> 
> (3) What is your year range of DateAndTime; do you need or use 
> DateAndTimes more than 5/10/50 years into the future (or the past)?
> 
> (4) How do you handle DateAndTime printing?
> 
> (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or 
> added your own methods to DateAndTime or DateAndTimeANSI?  If this is 
> general functionality that could be useful to include in the base, 
> please let us know.
> 
> (6) DateAndTime instances would need to be immutable, to be 
> interoperable with SmallDateAndTime. If you are using methods that do 
> update a DateAndTime, such as offset: or beRounded, does your code 
> expect the receiver to be modified?
> _______________________________________________
> GemStone-Smalltalk mailing list

> GemStone-Smalltalk at .gemtalksystems

> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
> 
> _______________________________________________
> GemStone-Smalltalk mailing list

> GemStone-Smalltalk at .gemtalksystems

> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>   
> _______________________________________________
> GemStone-Smalltalk mailing list

> GemStone-Smalltalk at .gemtalksystems

> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk





--
Sent from: http://forum.world.st/Gemstone-S-f1461796.html