2015-06-03 17:57 GMT-03:00 Stephan Eggermont <[email protected]>: > On 03/06/15 22:21, Esteban A. Maringolo wrote: >> >> 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <[email protected]>: >>> 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
