[GemStone-Smalltalk] DateAndTime users' questionnaire

[Bob Nemec]

 (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

 DateAndTime now - almost always used a 'created' or 'changed' timestamp. 
DateAndTime secondsUTC:offset: - only because we use our own code to store DateAndTime values as integers

(2) Do you need DateAndTimes with resolution finer than a microsecond?

No. Seconds is fine. 
(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)?

No. 30 years in the past would be the oldest for us. 
(4) How do you handle DateAndTime printing?

Use use our own displayString which outputs YYYY-MM-DD HH:MM:SS ... i.e. ISO with a space between date and time instead of a 'T'
(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.

No.
(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?
No. We tread DateAndTime instances as immutable. 

Bob NemecKORE

    On Friday, June 19, 2020, 09:36:54 p.m. EDT, Paul Baumann via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> 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 lists.gemtalksystems.com> 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 lists.gemtalksystems.com
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20200622/cc3c76b3/attachment.htm>