Question

我正在寻找更好地理解以下用户故事：

约翰在西德尼工作。早上9点，他在一个在苏黎世服务器上运行的网络应用程序中记录一个事件。第二天，他前往纽约参加紧急会议，讨论该事件。在会议期间，他按日期和时间搜索活动。

正如我所看到的，这里至少有两个问题：

我应该如何在数据库中保存时间戳
我应该如何在UI中展示它们

当John搜索事件时，他会知道它发生在9:00，但他应该在网络浏览器中输入什么？当他只是输入“9:00”作为时间戳时他不会找到任何东西，因为那可能是苏黎世或纽约时间（因为事件尚未找到，应用程序无法知道它发生在Sidney，所以它无法自动选择正确的时区。

向用户询问可能包含时区的时间戳有什么好方法？

第二个问题是如何显示结果。如果来自全球各地的团队需要讨论该事件（并找到相关事件，请考虑一次针对全球多个站点的破解者攻击）。

显示可能在不同时区创建的时间戳的好例子是什么？

注意：请专注于要求的可用性。我可以自己弄清楚数据库映射。目前，我不确定工作流程。它应该以非侵入性/直观的方式询问/提供必要的信息。如果可以，请提供已解决此问题的现有网络应用程序的链接。

Answer 1

存储时间戳的问题很简单：将它们存储在UTC中。

至于显示它们，采用设备的时区设置并将其用作当前时区是有意义的。也就是说，“时间输入”框旁边应该有一个时区下拉列表，默认为设备的当前时区，因此用户可以根据需要进行更改。

大多数用户可能不会更改或根本不更改时区。在大多数情况下，您概述的情况并不常见。通过使用合适的默认值实现下拉列表，您应该能够为那些移动的人提供足够的便利（因为他们通常比非旅行者更了解时区）。

事实上，更好的方法是在首次运行应用时保存设备设置的时区，然后查看它是否会发生变化。如果确实发生了变化，那么用户可能是旅行者，并且可能会受益于时区下拉。否则，只是不显示下拉列表并默认显示设备时区（因为用户不需要知道它们）。在任何一种情况下，在应用程序中都有一个允许用户手动显示/隐藏时区下拉列表的设置。

总结以上内容：

首次运行时，请保存设备设置的时区。
将该时区用作默认时区。总是假设时区。
如果设备切换时区，请添加下拉列表以选择事件所在的时区，默认为设备自己的时区。
添加一个选项以手动显示/隐藏此时区下拉列表。
始终以UTC格式存储时间戳。

Answer 2

在我们的应用程序中，我们通常会在首次注册时存储用户的时区，如论坛网站上常见的那样，始终显示时区。

至于存储日期，UTC是要走的路。转换为UTC并将其粘贴到数据库中。在检索时，只需将时间转换为为用户设置的时区。

我必须解决类似的用例，其中可以向Web应用的所有用户发送自定义通知，例如“新年快乐”。由于用户遍布全球，我们需要根据时区显示通知。在UTC中存储时间戳很好地满足了我们的目的，没有打嗝。

在您的使用案例中，如果您没有在某个地方存储用户时区，那么除非您开始使用像gmaps这样的某种位置检测，否则您将永远无法准确地返回搜索结果，但是这不可靠。因此，您每次都需要询问时区，以确保用户知道他在网站上输入的内容。

如果您有时区信息，则应使用时区设置运行整个Web应用程序。因此，当用户搜索9:00时，他将使用悉尼时区进行搜索。另一方面，如果他坐在纽约时创建一个活动，他将用悉尼时区创建一个活动。我们通过在显示日期时始终显示时区来解决此类情况。

希望它有所帮助！：）

Answer 3

UTC。保持简单。
使用与用户最相关的时区。

如果您知道用户将要参加悉尼或前往悉尼参加活动，那么在安排交通活动时，他们将在该时区思考。他们目前在纽约的事实在很大程度上是无关紧要的。当然，如果您的应用在各个时区显示日期，则应始终在日期旁边显示时区，例如 09:00 EST 。

如果它不会使您的界面过于混乱，您可以在事件时区和本地时区显示日期，例如 2012-06-13 09:00 EST（2012-06-12 19:00 EDT）。

我认为搜索是一个类似的问题，有一点需要注意：我们可以容忍误报（得到我们没想到的结果），但我们不能忍受假阴性（没有得到我们期待的结果）

同样，我会专注于向用户搜索最相关的时区（例如，事件时区），并在搜索结果中优先考虑这些结果，但您也可以返回与其他时区相匹配的事件。用户（例如当地时间）。如果这样做，您应该在匹配的时区中显示事件日期，特别是如果您突出显示匹配的文本。

Answer 4

在这里，我提供了最佳可用性的建议，而没有太多关于实施可行性的问题。
1.对于在db中存储事件的第一期，每个人都同意将其存储在UTC

中 2.为了提供最佳用户体验，请保存用户时区的历史记录。如果你可以节省时区变化的时间戳，那就更好了。这将使我们能够让用户自由查询，而无需每次都明确指定时区。

因此，通过这些功能，让我们看看＆＃34; 9.00＆＃34;通过   约翰将被处理：
有了上述功能，现在我知道了   约翰已经在2个时区直到约会（或获得时区列表   提到的时期）。因此，我将从悉尼时区转换为UTC，以及   触发查询。同时将9.00从NewYork时区转换为UTC，点燃一个   查询。在结果中，我将向John显示2行，显示他所做的事情   9.00在悉尼和纽约9.00。在这种情况下纽约线将是空白的，但我认为仍然应该向用户显示，只是为了通知   我也在搜索这个时区。

3.询问用户可能包含时区的时间戳的好方法是什么？

如果他的时区最近被更改，每当他登录申请时，   应该发出通知，更改您的默认时区   到本地时区。
在创建事件时，让我们说用户选择   时区从下拉。让我们通过提供所有选项来减轻用户的负担   世界的时区。下拉的第一个选项应该是当前时间   用户设备区域。之后的时区来自他的历史   时区，然后是UTC，然后是他从未有过的剩余时区   用到日期。

4.如果来自全球各地的团队需要讨论该事件，如何显示结果：

我想在2个或更多团队之间划分这个用例只有2支球队，我希望每支球队都能看到时区在其当地时区和其他团队的时区。（一世个人更喜欢在另一端的人的时区谈论他的安排会议时的便利性）。对于2个以上的团队，它最好考虑更常见的时区，即UTC。所以在这种情况下，每一个用户应该在UTC和默认情况下看到2个时区的时间戳时区。

这些建议的目的是用户不需要在当地时间进行任何计算，但同时他应该能够在其首选时区内流利地与其他用户进行通信。

Answer 5

好的，我采用了与其他方法不同的方法：

首先，我事先做了一些事情。

列出活动的人有智能手机（如果是浏览器，我不必做出这些假设）：

GPS
HTML5功能。
Javascript功能

如何在数据库中保存时间戳？

解决方案：显然 UTC ，我覆盖了以下程序：

步骤1.使用Geolocation API使用用户的地理位置

    window.onload = getMyLocation;

    function getMyLocation() {
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(displayLocation);
        } else {
            alert("Oops, no geolocation support");
        }
    }

    function displayLocation(position) {
        var latitude = position.coords.latitude;
        var longitude = position.coords.longitude;
        var div = document.getElementById("location");
        div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

步骤2.将（Long，Lat）作为一些（Lat，Long）与时区（如果{{}}}（使用标志R以使纬度转换为时区）的时间区域的对话给予用户时区。

=＆GT; 用户时区是在没有用户输入的情况下确定的（我使用这个是因为你不能简单地假设用户知道他居住的地方的时区，我知道我的时区只在几个月之后或在该地方发生了什么： P，非常愚蠢！）

每个事件表都有Timezone，Event＆amp;所以也可以CityName 然后创建另一个基于CityName s分类的数据库表。所以这里用户将有两列

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________|

对于UI

=＆GT;使用Google Calendar API或某些Calendar API的

相关阅读材料：

Yahoo API
Determine timezone from latitude/longitude without using web services like Geonames.org

我知道它只是想知道如何解决这个问题。但看看有多准确＆amp;当使用设备API

希望它有所帮助！

Answer 6

对于这种特殊情况，我会存储本地和UTC时间。 UTC有点重要，用于同步和转换时间到当前时区。本地用于搜索和其他信息，例如：

你开了个会：

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

或类似的东西。另一种方法是存储创建时区，并在运行时进行转换（这在用户将更改会议时间的情况下尤其更好）。无论哪种方式，主要原因是能够恢复原始创建时间，以便用户可以参考它。

Answer 7

我应该如何在数据库中保存时间戳

在创建活动时，我会存储UTC时间和本地时区（又名creation time zone）。我会使用我存储的内容将UTC时间转换为本地时间（又名creation time）并将其与UTC时间和creation time zone一起存储。

注意：我可以从一开始就存储本地时间，但是当用户搜索某个事件时，我希望转换为本地时间。我也希望服务器能够检测到客户端所在的时区。

我应该如何在UI中展示它们

当用户搜索“9:00”时，我会搜索UTC中包含“9:00”的事件或 creation time 或当地时间。对于结果，我将在creation time中显示一个结果表（这是为了显示可能在不同时区创建的时间戳，因为我们假设用户正在查找他为其创建事件的时间无论他在哪里。），并在下面显示第二个结果表，其中包含相关结果，可能还有标题，“不是您要查找的内容？请参阅相关结果”（这些包括剩余的UTC和当地时间结果）。

总的来说，我会按UTC时间显示UTC时间，本地时间，creation time和creation time zone（即创建它的事件的当地时间和时区），所以你可以看到哪个事件是第一个，如果在两个不同的时区内安排了9个两个不同的事件。

如何处理我的webapp中的时区？

7 个答案: