2015-06-03 17:57 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
On 03/06/15 22:21, Esteban A. Maringolo wrote:
2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
For performance reasons you'll probably often want to map to smallint value objects. And lose the date abstraction the database provides me with? It is up to the database how to optimize the store of its datatypes.
Uhm, no on the smalltalk side. A DateAndTime is large and slow.
A Date is larger in Pharo, it has two objects: aDateAndTime and aDuration. And one the rules that I value the most in the long time is the "Rule of Representation: Fold knowledge into data so program logic can be stupid an robust". Regarding the "Time oriented Databases" book you recommended, it makes a clear distinction about instants and intervals in a whole chapter (Chapter 3), and in all the chapter and implementations of SQL-92 (superseeded by SQL-2011) I couldn't find a single use case nor mention of a Date with a timezone. I think this discussion is depleted, Pharo Date implementation is as it is. Every suggestion is a workaround to a design choice made a lot of time ago. Thanks for your time. Esteban A. Maringolo