Thanks for the response Hector, I guess I was coming from the point of view that - can we assume an app will be doing the same thing it is now with regard to functionality in, say, 28 years time? but then I think that question is dependant on the nature of the app and how critical its operation is?
Also do you think the issue with Zend_validate_Date is because of the 32-bit integer limit like I assumed? Thanks Daniel On 8 October 2010 22:52, Hector Virgen <[email protected]> wrote: > That's only 28 years into the future. I think it's perfectly valid to worry > about those dates not working -- consider, for example, a mortgage company > that signs 30-year loans. I'm sure they'd want to show the expected maturity > date for a mortgage signed today. > > -- > *Hector Virgen* > Sr. Web Developer > Walt Disney Parks and Resorts Online > http://www.virgentech.com > > > > On Fri, Oct 8, 2010 at 2:01 PM, Daniel Latter <[email protected]>wrote: > >> related to below but does anyone think its silly to be messing with dates >> in >> an app so far in future? Our use case is that we are storing driving >> licences and their expiry date - to be checked in future - and we are >> using >> Zend_Validate_Date to validate input...? >> >> Obviously we can just extend Zend_Validate_Date and override isValid >> method >> but just wondering if anyone has any good arguments against above scenario >> or to why we shouldn't worry about dates so far in future?? >> >> Daniel. >> >> On 8 October 2010 21:52, Daniel Latter <[email protected]> wrote: >> >> > Hi all, >> > >> > I posted an issue (as in the title of this post) on the tracker: >> > >> > http://framework.zend.com/issues/browse/ZF-10525 >> > >> > I have later realised it may have something to do with the 32-bit >> integer >> > limit but I dont understand why Zend_validate_Date starts to return true >> > after the date mentioned (19/03/2042) ? >> > >> > Is it because overflow occurs in the bit pattern for the number so the >> > number falls back into the 32-bit integer range again? >> > >> > Thanks >> > Daniel >> > >> > >
