Функция для получения сегодняшней даты?

Question

Я создаю «выбор» внутри шаблона контракта, который требует проверки сегодняшней даты.Мой код DAML выглядит следующим образом:

controller dealer can
      Add_Car : CarId
        with
            startCoverage: Date

        do
          -- Check for a legal start date
          assert (
            startCoverage > *today* --should check that its not before today
            )
          create this with date_vehicle_added = startCoverage

Какое название функции я могу использовать для получения текущей даты?Он должен идти туда, где написано "*today*".

Answer 1

tldr: Используйте getTime : Update Time и toDateUTC : Time -> Date, но помните о подводных камнях.Предпочтительно использовать шаблон «Нотариально заверенная дата», если это возможно.

Моделирование даты / времени неявным образом

Моделирование даты и времени всегда является тонкой проблемой, вдвойне, когда речь идет о детерминированной распределенной системе, такой какв качестве цифровой книги.DAML предоставляет примитивную функцию getTime, которая будет возвращать «Эффективное время книги» (LET), которое, как гарантирует модель книги, будет монотонно увеличивающимся значением времени (в миллисекундах), которое ограничено с точностью до дельты, определенной в книге.Часы UTC.Это можно преобразовать в дату UTC с помощью функции toDateUTC в DA.Date.Это прямолинейный ответ на ваш вопрос, но есть несколько предостережений.

1. Это время и дата в UTC, вам придется явно смоделировать, как это соответствуетвремя.Поскольку DAML является детерминированной распределенной системой, локального времени не существует, поскольку любая конкретная транзакция должна быть детерминистически выполнена в нескольких часовых поясах.

2. Неоправданное использование сравнения даты и времени может привести к тому, что контракты будутнеявно остановился из-за времени.Если выбор защищен проверкой времени по настенным часам, это может означать, что любая задержка в обработке вашего приложения может привести к тому, что выбор станет недействительным.Удостовериться, что вы правильно обрабатываете этот случай в коде приложения, - это тонкая проблема - и поскольку это неявный параметр по вашему выбору, невозможно избежать оперативного вмешательства, чтобы избежать этой проблемы, даже если вы получили предварительное предупреждение.

3. Интеграционное тестирование вашей модели и приложения становится недетерминированным и неповторяемым при наличии явных временных сравнений.Хотя вы можете написать повторяющиеся Scenario тесты для вашей модели, поскольку у вас есть явный контроль над LET, это не будет работать с приложением вне книги.

Моделирование Дата / ВремяЯвно

Альтернативой является шаблон нотариально заверенной даты.Здесь подписавшие договор договариваются о том, чтобы доверенная сторона заверяла текущую дату.Это нотариальное заверение принимает форму договора CurrentDate на бухгалтерскую книгу.Этот договор имеет нотариуса в качестве подписавшего, и, как правило, у него есть один выбор потребителя, контролируемый нотариусом, для продвижения даты.

Если вы используете этот подход, ваш выбор Add_Car будет принимать дополнительный параметр currentDate : ContractId CurrentDate, который вы можете рассматривать как контролер, предоставляющий свидетельство или доказательство того, что согласованный нотариус засвидетельствовал текущую дату для целей настоящего договора.Это решает проблемы с неявной моделью времени, таким образом:

1. Поскольку Дата теперь указана в регистре, часовые пояса становятся явными в ходе выполнения контракта CurrentDate.

2. Хотя договор все еще может быть приостановлен, если нотариус продвигает контракт на текущую дату, явный характер управления датами означает, что: а) любое упражнение, упорядоченное до обновления даты нотариуса, будет успешно обработано;что означает, б) Теперь есть возможность оперативного вмешательства, где вы заранее предупредили, что обработка для данного дня отстает от графика - при условии, что такое вмешательство предвидится и разрешено в нотариальном соглашении.

3. Поскольку работа вашей системы опять-таки является чистой функцией содержимого регистра, поведение более крупного приложения становится детерминированным и повторяемым.Это значительно сокращает усилия, необходимые для обслуживания, тестирования и отладки.

По этим причинам я бы рекомендовал использовать шаблон «Нотариально заверенная дата», где это возможно, с сохранением неявной обработки «Дата» для тех случаев, когдаальтернативы действительно нет.

Answer 2

Перед вашим assert вы можете связать результат getTime функции .Затем я предлагаю преобразовать startCoverage в Time с помощью функций toGregorian и datetime в DA.Date .

Возможно, у вас недостаточно информации для выполненияэто правильно с вашим примером кода;Date - это «локальная дата», которую, как ожидается, следует интерпретировать относительно некоторого часового пояса, тогда как Time - это абсолютное смещение эпохи UNIX.Именно по этой причине в руководстве указано так много предостережений для toDateUTC, и я рекомендую избегать этой функции.

Кроме того, имейте в виду, что доступно только «эффективное время книги», котороене совсем то же самое, что и «текущее время».Конечно, для целей живого упражнения Add_Car результат getTime будет соответствовать текущему времени.Тем не менее, транзакции обязательно воспроизводимы (для проверки или по другим причинам), и для этих исполнений getTime будет производить то, что первоначально делал при выполнении.Вы не можете использовать getTime для определения количества времени настенных часов, которое DAML потребовалось для выполнения какого-либо кода, и это означает, что даже во время живой книги эффективное время не соответствует точно настенным часам.Когда вы запускаете тестовых сценариев , время начинается в эпоху UNIX и может быть увеличено вручную в вашем сценарии, как того требует ваш тест;на самом деле я могу порекомендовать использовать pass или passToDate для проверки самого контракта, который вы пишете.