作为一名软件测试人员，我遇到了一个关于在时间旅行的平台上进行测试的事件。 （根据测试要求，可以手动设置时间到过去/未来）
因此，申请时间不必与当地时间相同......或者应该是相同的吗？
我发现了一个由我的本地时间和应用时间不一致引起的错误。简单描述：有两种验证。验证＃1验证客户端的用户输入（并使用本地日期进行验证），验证＃2验证服务器端的用户输入（并使用服务器日期）。两种验证都符合项目规范中指定的业务规则。 （它没有指定它应该在本地运行还是在服务器端运行）当这些日期之间存在不一致时，会产生意外结果。
然而，该错误被开发拒绝，我的测试错误，并且客户有责任同步这两个日期。
老实说，我不明白我的当地时间与申请行为有什么关系。有很多功能和规则，并且所有这些都使用服务器时间作为参考点。但由于客户端验证是由javascript完成的，参考点是本地时间（因为它的默认行为，它不是故意的）。
所以我只是问你的意见。你认为这是一个错误还是我对当地时间重要性的不理解？您是如何在项目中（作为测试人员或开发人员）处理这些事情的？这不仅仅是测试和服务器时间旅行的问题，而是关于客户＆＃34;时间旅行＆＃34 ;? （例如，不同的时区）。你是否用任何一种efford来处理这些事情，或者只是相信，那就是当地时间不好=客户问题＆＃34;那不是发展问题吗？
答案 0 :(得分：0)
一般来说，它实际上取决于您的应用程序，它的功能以及所需的内容。但是，作为最佳实践，＆＃34;申请时间＆＃34;始终是UTC。作为另一种最佳实践，永远不要相信客户时代最终用户的计算机时间可能完全关闭或不同步有很多原因。
在我使用过的几乎所有应用程序中，我们都将应用程序服务器设置为UTC。对于最终用户，我们让他们设置他们的时区，我们用它来确定时区偏移量。因此，例如，如果最终用户选择＆＃34;东部时区＆＃34;我们存储该设置以及-5小时的偏移（为了简洁而忽略夏令时）。如果您没有将用户设置存储到数据库，您仍然可以通过客户端首选项屏幕或通过javascript自动获取其时区。但关键因素是忽略了他们的时间，只是得到他们的时区/偏移量。然后将该时区发送到服务器，以便您可以使用服务器的准确时间来转换时间。这样，您始终可以获得准确的服务器时间，但随后可以参考用户的本地时间，您可以将其用于报告，逻辑或显示值。
所以回答你的问题：在大多数情况下需要考虑一个糟糕的当地时间，这将成为你的问题。最终用户不会检查他们的时钟以确保他们是准确的，他们希望您的应用程序能够在没有IT人员帮助的情况下工作。