我正在合同模板中创建一个“选择”，需要检查今天的日期。我的 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*”的地方。
【问题讨论】：
标签： daml
tldr: 使用getTime : Update Time 和toDateUTC : Time -> Date，
但要注意陷阱。最好使用公证日期
如果这是可能的模式。
建模日期和时间总是一个微妙的问题，当
处理确定性的分布式系统，例如数字
分类帐。 DAML 提供了一个原始函数getTime，它将返回
账本模型保证的“账本有效时间”（LET）
一个单调递增的时间值（以毫秒为单位），即
限制在挂钟 UTC 时间的分类帐定义的增量内。
可以使用 toDateUTC 函数将其转换为 UTC 日期
DA.Date。这是您问题的直线答案，但有
一些警告。
此时间和日期采用 UTC，您必须明确建模 这如何对应于当地时间。由于 DAML 是确定性的， 分布式系统，没有本地时间作为任何给定的事务 必须跨多个时区确定性地执行。
无偿使用日期/时间比较可能导致合同被 由于时间的流逝而隐含地停滞不前。如果选择受到保护 通过检查挂钟时间，这可能意味着任何延迟 您的应用程序处理练习可能会导致选择 变得无效。确保你在你的 应用程序代码是一个微妙的问题——因为这是一个隐含的 参数由您选择，没有操作干预 即使您有提前警告，也可以避免该问题。
您的模型和应用程序的集成测试变为
在存在明确时间的情况下是非确定性和不可重复的
比较。虽然您可以为您的代码编写可重复的 Scenario 测试
模型，因为您在那里明确控制LET，所以这不会
练习你的账外应用程序。
另一种选择是公证日期模式。在此，签署方
合同约定受信任方对当前日期进行公证。这
公证采用分类账上的CurrentDate 合同的形式。
本合同以公证人为签字人，一般有
由公证人控制的单一消费选择，以推进
日期。
如果您使用这种方法，您的Add_Car 选择将需要额外的
参数currentDate : ContractId CurrentDate，你可以想
作为控制人提供证据或证明同意
为此目的，公证人已证明当前日期
合同。这解决了隐式时间模型的问题：
由于日期现在在账本上是明确的，因此时区在
CurrentDate 合约的进度。
虽然如果公证人提前了合同，合同仍可能被搁置 当前日期合同，日期管理手段的显性性质 a) 在公证日期更新之前排序的任何练习都将是 处理成功；这意味着，b) 现在有一个途径 您已提前警告的操作干预 某一天的处理进度落后于计划——假设这样 公证协议预期并允许干预。
因为您的系统操作再次是账本内容的纯函数，所以较大应用程序的行为变得确定性和可重复性。这大大减少了所需的工作量 用于维护、测试和调试。
出于这些原因，我建议使用公证日期模式，其中 这是可能的，为那些情况保留隐式日期处理 确实没有其他选择。
【讨论】：
在assert 之前，您可以bind the result of the getTime function。然后我建议通过toGregorian 和datetime functions in DA.Date 将startCoverage 转换为Time。
您的示例代码可能没有足够的信息来正确执行此操作； Date 是“本地日期”，预计会相对于某个时区进行解释，而 Time 是绝对 UNIX 纪元偏移量。正因为如此，手册中列出了对toDateUTC 的许多警告，我建议避免使用该功能。
此外，请记住，只有“账本有效时间”可用，这与“当前时间”并不完全相同。当然，对于Add_Car 的现场练习，getTime 的结果将对应于当前时间。但是，交易必须是可重放的（出于验证或其他原因），并且对于这些执行，getTime 将产生它最初在执行时所做的事情。您不能使用getTime 来确定 DAML 执行某些代码所花费的挂钟时间量，这意味着即使在实况练习期间，分类帐的有效时间也不精确对应于挂钟。当您运行test scenarios 时，时间从 UNIX 纪元开始，并且可以根据您的测试需要在您的场景中手动推进；事实上，我可以推荐使用pass 或passToDate 来测试您正在编写的合同。
【讨论】：