kefi, формат времени, который я приводил, взят с MSDN, используется в WMI и .Net FrameWork как минимум. Вы можете привести ссылки по этому рассуждению:

kefi пишет:

Дело в Вашем посте выше о том, с какого системного счетчика берется время, Я так думаю, что и %time% и Timer берут время с одного 1/18.2  сек счетчика , следовательно люди глядя в ту тему могут быть обмануты (если конечно не будут внимательны) на +-25 msec ( примерно 1/18.2=0.050 сек - абсолютная погрешность метода)

Мда, видно поспешил я , Просто я руководствовался одним простым принципом - здравым смыслом (ну Вы знаете - это, когда знаний нет, а решение принять хочется ) , но малось лопухнулся. Не 18 Гц , а 64.
Ну т.е. я подумал, а отчего же это Timer  %time% при распечатке представляется системой с точностью до сотых секунды (подумал , что это они 18.2 Герца натягивают, но несколько дело не так - 64 герца ) :
Вот решил поднять свои старые вопросы и обнаружил, что оказывается для большинства это 64 Hz, но все-равно не 1000Hz, как предполагает Ваш алгоритм (Т.е., попросту говоря, Timer , конечно , дает число секунд с точносьтю до микро, т.е. миллионных, но они стоя'т на месте в течении 1/64 секунды, видно формат расчитан на продвинутое в этом отношении железо, которого у обычного юзера нет,  короче, в той теме описано ... ).
В общем-то в той теме все решено, кроме того , чтобы решить этот топик без привлечения API функций, ну т.е., как это и нужно было бы для чистого скриптинга.

Выложил в Коллекцию первый пример: VBScript: текущее время в формате с миллисекундами (hh:mm:ss.fff).

Только вот заголовок там (да что там заголовок и содержание ) некорректен. Дело в Вашем посте выше о том, с какого системного счетчика берется время, Я так думаю, что и %time% и Timer берут время с одного 1/18.2  сек счетчика , следовательно люди глядя в ту тему могут быть обмануты (если конечно не будут внимательны) на +-25 msec ( примерно 1/18.2=0.050 сек - абсолютная погрешность метода)
Надо бы  озаглавить,  как в формате с сотыми, да и то обратить внимание , что погрешность будет +-2.5 единицы.

Но можно запустить её при старте самого VBS-скрипта и взаимодействовать с ней интерактивно во время исполнения.

Согласен, я как-то не подумал о такой возможности .

У меня, например, даже при приведённых в #1 региональных настройках времени ["sTimeFormat"="HH:mm:ss"], ведущий ноль заменяется пробелом при раскрытии переменной %time%:

В то же время в VBScript возвращается правильная трактовка с ведущим нулём:

WScript.Echo Time()
WScript.Echo Now()

С другой строны — я даже не занимался этим вопросом, чтобы понять «це баг о це фича» .

Давай учись вопросы задавать как следует

Аднака, чукча уже 12-й год учится в интернете , все никак научитться не может.

Очень интеллектуальная дискуссия.
Давай учись вопросы задавать как следует, чтобы хотя бы не ставить в тупик всех беспредельной нелепостью вопроса. Ты когда спрашиваешь, ставь себя на место потенциальных отвечающих. Представляй себе, как у них волосы шевелятся на голове от твоих "вопросов". Пиши и представляй себе, как твой вопрос читают, что могут подумать, прочитав, и т.д.

ПОЧЕМУ они у тебя есть в Now, а у меня нет ? Что непонятно-то ?

См. #4. Непонятно то, что у меня их нет в Now. Где ты там увидел миллисекунды в Now? Там есть микросекунды в строковой константе, которая набрана вручную на клавиатуре, исключительно для того, чтобы показать, что объект успешно обрабатывает микросекунды, работая с этим форматом даты.

если миллисекунд нет в строковом представлении даты, то их и не оказывается при автоматическом разборе этой строки объектом "WbemScripting.SWbemDateTime" В чём вопрос-то?

Так в этом самом и вопрос , пятый раз пытаюсь выпытать - ПОЧЕМУ они у тебя есть в Now, а у меня нет ? Что непонятно-то ?