> Geoffrey, if you're reading this, I'd love your comments on how useful > this would be in your case.
I am :) ok, I haven't looked at the code yet, but from your explanations it sounds attractive, especially in our situation. just like you, we don't necessarily need data validation since the data is coming mostly from database date/time fields. also similarly we would be creating objects for sql fields that may be infrequently manipulated in the codebase itself. so, take the overhead out of those kinds of things and you've made half my case for me :) the only sticking point would be the date math "exceptions" dave mentions. in my particular situation we deal with slices of time - the exact time of an event, when that event is visible on the web, what that time looks like to our servers on the west coast versus data entry on the east coast versus an attendee in australia, etc - so it's the date math that is driving force behind using DateTime in the first place. in essence, optimize away, but exploding object size when you need to do something real with it isn't much of a win. anyway, I hope you guys are taking my opinions appropriately - DateTime is clearly the right choice for perl DT logic IMHO for a variety of reasons, but I wasn't able to convince others to adopt it since their criteria for "right choice" was significantly different. so it's their arguments and mindset that I'm trying to convey :) --Geoff
