[GemStone-Smalltalk] DateAndTime users' questionnaire

Esteban Maringolo emaringolo at gmail.com
Fri Jun 19 18:02:38 PDT 2020

On Fri, Jun 19, 2020 at 8: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.

Although I don't use GS these days, I want to participate.
DateAndTime has always been an "expensive" object, and having it as an
immediate object is something I always wanted.

> (1) Which of the following messages do you use to create DateAndTime
> instances?
>   * DateAndTime now
>   * DateAndTime fromString:

Also fromUNIXTime: or equivalent.

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

Not even so. 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)?

+/- 10 years I'd say.

> (4) How do you handle DateAndTime printing?

Depends. Using it's ISO representation or a locale printer.

> (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?

I always treated DateAndTime as immutable, except when I was
optimizing something because I didn't have immediate DateAndTime!


More information about the GemStone-Smalltalk mailing list