Намерена грешка в XPages

Опитайте този код:

<xp:text escape="true" id="computedField4">
    <xp:this.value><![CDATA[#{javascript:
        var td= @Adjust(@Date(2015,3,1), 0, 1, 0, 0, 0, 0);
        return @Text(@Year(td))+","+@Text(@Month(td))+","+@Text(@Day(td));
    }]]></xp:this.value>
</xp:text>

Очаквана продукция: 2015,4,1

Действителна продукция: 2015,3,29

АКТУАЛИЗИРАНЕ

Това решава проблема, но има ли по-кратка версия:

<xp:text escape="true" id="computedField4">
    <xp:this.value><![CDATA[#{javascript:
        var cal= java.util.Calendar.getInstance();
        cal.add(java.util.Calendar.MONTH, 1);
        var td:Date= cal.getTime();
        return td.getFullYear()+","+(td.getMonth()+1)+","+td.getDate();
    }]]></xp:this.value>
</xp:text>

TIA.


xpages lotus-formula
person D.Bugger    schedule 01.03.2015    source източник
comment
Препоръчвам да не се фокусирате върху по-кратко решение. Това работи добре. Най-хубавото е, че не използвате @formulas.   -  person David Leedy    schedule 01.03.2015

Отговори (2)


arrow_upward
2
arrow_downward

Не мога да възпроизвеждам на 9.0.1 FP2 HF1 на Windows и @Date(2015,3,1) в изчислено поле в локал на Обединеното кралство се връща на 1 март, както се очаква. Но това може да бъде фактор .xsp?documentId=5655E1203988BEF0852578CB0066A339. Ще преминете през лятното часово време, както и ще комбинирате местно и UTC. Актуализацията е по-добрият метод. Тогава използвате само Java обекти, така че не разчитайте на вътрешни манипулации. Освен това имате работа с Calendar обекта, който има както дата, така и час и е специфичен за локала, вместо да зададете @Date() без време, след което да стартирате @Adjust, което го прави и също преминава през началото на DST.

person Paul Stephen Withers    schedule 01.03.2015

arrow_upward
1
arrow_downward

Опитах го и открих, че получавам 2015, 4, 1. Коя версия на Domino използвате? Пробвах го на 9.0.1FP2 HF384 на Win 64.

person Rob Mason    schedule 01.03.2015
comment
Мога да възпроизведа проблема на Buggers и да получа 2015,3,29. Използвам 9.0.1 FP3 Win64. Може ли да е регионален проблем? Използвам регион Швеция - person Thomas Adrian; 01.03.2015
comment
Съжалявам, трябваше да спомена това: Domino 9.0.1 FP2 на Windows/7/64 6.1 - person D.Bugger; 01.03.2015
comment
Моят е настроен за UK. Странно. Прочитайки го отново, изглежда, че вътрешно системата смята, че датата е 29 февруари и след това добавянето на месец дава 29 март. Ще ми е интересно да видя какво връща @Date(2015,3,1), преди да бъде коригирано. По този начин можем да видим дали това е Date или @Date() проблем, а не @Adjust() проблем. - person Rob Mason; 01.03.2015
comment
Моето предположение: сбъркал е месеца. По някакъв начин смята, че се нуждае от броя на дните за февруари, добавя 28 и връща 29-ия. - person D.Bugger; 02.03.2015
comment
Вярвам, че това е проблем с регионалните настройки, трябва да посочите часова зона, мисля, че ще получите правилната дата, ако добавите 1 месец и 1 час. stackoverflow.com/questions/11115961/ - person Fredrik Norling; 02.03.2015
comment
Така че смятате, че отнема 1 март 00:00 полунощ тук (TZ+1), което е 28 февруари 23:00 GMT, добавя един месец, за да пристигне на 28 март 23:00, което е 29 март 00:00 тук... много правдоподобно наистина! Но дали това е правилното поведение? Между другото, направих това вчера, използвайки @Today, и получих грешен отговор. - person D.Bugger; 02.03.2015