Сечь как по мне работает следующим алгоритмом:
Доказать сможете?
На ваш аргумент я отвечу следующее.
Клиент тоже не выдаёт синтаксической ошибки на дате 01/02/2009, когда настройки ДД.ММ.ГГГГ, а вот на дате 16/11/2009 уже выдаёт ошибку. Т.е. он пытается распознать дату, но когда ему не удаётся - генерируется эксепшен.
Ещё в подтверждение своей гипотезы приведу кусок NRPC-лога. Кто не знает, NRPC - это Notes Remote Procedure Call - протокол общения Notes-клиента с сервером. Агента запускал того же под локалью с ДД.ММ.ГГГГ. Также я включил режим протоколирования вывода в статус бар.
[096C:0002-0F40] (123-299 [128]) READ_OBJECT(REPC325735C:003B7AB5-RRV0000073E,0x10 at 0x140): 0 ms. [26+36=62]
[096C:0002-0F40] (124-299 [129]) GET_NOTE_INFO_BY_UNID: 0 ms. [52+66=118]
[096C:0002-0F40] (125-299 [130]) OPEN_NOTE(REPC325735C:003B7AB5-NT000006A2,03400000): 0 ms. [48+5238=5286]
[096C:0002-0F40] 16.11.2009 15:31:52 Status Msg: 16.11.2009 15:31:52 ZE3
[096C:0002-0F40] (126-299 [131]) SEARCH: 157 ms. [94+706=800]
[096C:0002-0F40] 16.11.2009 15:31:52 Status Msg: [2] Notes error: Formula Error (@Created<[06/29/2010])
[096C:0002-0F40] (127-299 [132]) SEARCH: 188 ms. [94+706=800]
[096C:0002-0F40] (128-300 [133]) GET_OBJECT_SIZE: 0 ms. [28+24=52]
[096C:0002-0F40] (129-300 [134]) WRITE_OBJECT(REPC325735C:003B7AB5-RRV0000073E,0x30 at 0x0): 0 ms. [74+12=86]
NRPC-вызов [131] - это Search под номером 1 в агенте.
Далее, вместо Search под номером 2 вывелось сообщение об ошибке в статус бар.
И [132] NRPC-вызов это Search под номером 3.
Других SEARCH нет. Значит, никакого запроса на сервер по второму Search не передавалось. Значит серверу даже не дали шанса "перевести", как Вы выразились, эту дату.