DateAndTime users' questionnaire
Locked
DateAndTime users' questionnaire
 
|
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? _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: DateAndTime users' questionnaire
|
|
At customer request, we're working on a SmallDateAndTime class for We have many persistent DateAndTime instances. We also have many more persistent Date instances, which I believe would be even more space optimising in our case. Another similar and useful optimisation would be a number representation that keeps up to 8 decimal places (even less). We would use that for monetary amounts and values of instruments such as mutual funds. We have millions of those. There are design tradeoffs in resolution, range, printing, etc., and it yes, mostly * DateAndTime nowWithScale: yes, infrequently * DateAndTime year:day:hour* or year:month:day:hour* DateAndTime class date:time: (2) Do you need DateAndTimes with resolution finer than a microsecond? No (3) What is your year range of DateAndTime; do you need or use More than 10 years in the past, less than 50. No future DateAndTimes (4) How do you handle DateAndTime printing? asString date <with different date formatting>; space; time asString (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or We use TimeStamp, but this could just as well be DateAndTime, AFAIK. Lots of printing methods, all rather specific and not really nice for inclusion in the base. (6) DateAndTime instances would need to be immutable, to be No, it can be immutable. _______________________________________________ _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |