在原來公司的項目組工作的過程中，自己實現(xiàn)了一個用于校驗用戶輸入數(shù)據(jù)合法性的Javascript Validation Framework。在這個Framework實現(xiàn)的過程中，在參考了一些網(wǎng)上資源之后，自己寫了一個日期校驗的函數(shù)，滿心以為這個校驗函數(shù)已經(jīng)夠完備了，結(jié)果還是經(jīng)歷了多次的修改。   

function validateDate(year, month, day) 
{
    var regex = new RegExp(/S/);  
    if(regex.test(day)&& regex.test(month) && regex.test(year)) 
    {
        var regExp = new RegExp(/d/);
        if(!regExp.test(day)|| !regExp.test(month) || !regExp.test(year))
            return ("The date fields contains non-number.");
        var tempDateValue = year + "/" + month + "/" + day;
        if(tempDateValue.length < 6||tempDateValue.length > 10)
            return ("The length of date fields is invalid."); 
        var tempDate = new Date(tempDateValue);
        if(isNaN(tempDate))
            return ("The scope of date fields is invalid.");   
        if(parseInt(year) > 1900 && parseInt(year) < 2500 && ((tempDate.getUTCFullYear
()).toString()==year) && (tempDate.getMonth()==parseInt(month)-1) && (tempDate.getDate()
==parseInt(day)))
            return ("The date fields is OK.");
        else
            return ("The date fields is invalid.");
    }
}

                                                           (為了說明問題，代碼略有改動)

        1、使用測試數(shù)據(jù)：year="2003",month="08",day="01"。這原本是一個合法的日期，然而出乎我的意料，返回的信息居然是：The date fields are invalid。根據(jù)返回的信息，將錯誤定位在最后一個條件語句。經(jīng)過仔細(xì)的檢查，發(fā)現(xiàn)parseInt("08") = 0，條件語句返回自然是false了。為什么parseInt("08")會得到這樣的結(jié)果呢？原來parseInt在沒有指定轉(zhuǎn)化進制的時候，是根據(jù)字符串對應(yīng)的進制進行轉(zhuǎn)換，而以0開頭的字符串都默認(rèn)為八進制的，那么在八進制中8是不存在的，因此返回0也就不奇怪了。修改辦法就是將所有的parseInt函數(shù)指定進制即可，如parseInt(month)改為parseInt(month,10)。
        2、使用測試數(shù)據(jù)：year="2000",month="01",day="01"。這個日期也是OK的，然而返回的信息也是：The date fields are invalid。這次的錯誤又是因為什么呢？原來錯誤在于getUTCFullYear，由于中國處于時區(qū)的東八區(qū)，而通過var tempDate = new Date(tempDateValue)獲得日期的對象，默認(rèn)是包含具體的時間，且初始化值為00:00:00。那么在中國是跨入二十一世紀(jì)了，可是在格林威治卻仍然是1999年，那么出錯也是自然的事情了，修改辦法是將getUTCFullYear改為getFullYear即可。