我希望更好地理解以下用户故事:
约翰在悉尼工作。早上 9:00,他在苏黎世服务器上运行的 Web 应用程序中记录了一个事件。第二天,他前往纽约参加紧急会议,讨论这一事件。在会议期间,他按日期和时间搜索事件。
在我看来,这里至少有两个问题:
- 我应该如何在数据库中保存时间戳
- 我应该如何在 UI 中呈现它们
当 John 搜索事件时,他会知道它发生在 9:00,但他应该在网络浏览器中输入什么?当他只输入"9:00"作为时间戳时,他不会找到任何东西,因为这可能是苏黎世或纽约时间(由于尚未找到事件,应用程序无法知道它发生在悉尼,因此它无法自动选择正确的时区)。
向用户询问可能包含时区的时间戳的好方法是什么?
第二个问题是如何显示结果。如果来自世界各地的团队需要讨论该事件(并找到相关事件,请考虑同时针对全球多个站点的破解攻击)。
显示可能已在不同时区创建的时间戳的好示例是什么?
注意:请专注于要求的可用性。我可以自己弄清楚数据库映射。目前,我不确定工作流程。它应该以非侵入性/直观的方式询问/呈现必要的信息。如果可以,请提供指向已解决此问题的现有 Web 应用程序的链接。
存储时间戳的问题很简单:以 UTC 格式存储它们。
至于显示它们,采用设备的时区设置并将其用作当前时区是有意义的。也就是说,"时间输入"框旁边应该有一个时区下拉列表,默认为设备的当前时区,因此用户可以根据需要更改它。
您的大多数用户可能不会更改太多时区,或者根本不会更改时区。在大多数情况下,您概述的情况并不常见。通过实现具有适当默认值的下拉列表,您应该能够为那些四处走动的人提供足够简单的操作(因为他们通常比非旅行者更好地了解时区)。
事实上,更好的方法是保存设备首次运行时设置的时区,然后查看它是否发生变化。如果它确实发生了变化,那么用户可能是旅行者,并且可能会从时区下拉菜单中受益。否则,只需不显示下拉列表并默认为设备时区(因为用户不需要了解它们)。在任一情况下,请在应用中设置允许用户手动显示/隐藏时区下拉列表。
总结以上内容:
- 首次运行时,保存设备设置的时区。
- 使用该时区作为默认时区。始终假定时区。
- 如果设备切换时区,请添加一个下拉列表以选择事件所在的时区,默认为设备自己的时区。
- 添加一个选项以手动显示/隐藏此时区下拉列表。
- 始终以 UTC 格式存储时间戳。
在我们的应用程序中,我们通常在首次注册时存储用户的时区,就像在论坛网站上经常看到的那样,并始终显示时区的时间。
至于存储日期,UTC是要走的路。转换为 UTC 并将其粘贴到数据库中。检索时,只需将时间转换为为用户设置的时区即可。
我必须解决一个类似的用例,其中自定义通知(如"新年快乐")可以发送给 Web 应用程序的所有用户。由于用户遍布全球,我们需要根据时区显示通知。以 UTC 格式存储时间戳很好地达到了我们的目的,没有打嗝。
在您的用例中,如果您没有将用户时区存储在某个地方,您将永远无法在不要求用户输入的情况下准确返回搜索结果,除非您开始使用某种位置检测,就像 gmaps 一样,但这并不可靠。因此,您需要每次都询问时区,以确保用户知道他在网站上输入的内容。
如果确实有时区信息,则应使用时区设置运行整个 Web 应用。因此,当用户搜索 9:00 时,他将使用悉尼时区进行搜索。另一方面,如果他坐在纽约创建一个活动,他将创建一个使用悉尼时区的活动。我们通过始终在显示日期时显示时区来解决这种情况。
希望对您有所帮助! :)
-
世界协调时。保持简单。
-
使用与用户最相关的时区。
如果您知道用户将在悉尼或前往悉尼参加活动,那么他们在安排前往活动的交通时会考虑该时区。他们目前在纽约的事实在很大程度上无关紧要。当然,如果您的应用显示不同时区的日期,则应始终在日期旁边显示时区,例如美国东部时间 09:00。
如果它不会使您的界面过于混乱,您可以以事件时区和本地时区显示日期,例如 2012-06-13 09:00 EST (2012-06-12 19:00 EDT)。
我认为搜索是一个类似的问题,但有一个警告:我们可以容忍误报(得到我们意想不到的结果),但我们不能忍受假阴性(没有得到我们期待的结果)。
同样,我将专注于搜索与用户最相关的时区(例如事件时区),并在搜索结果中优先考虑这些结果,但您也可以返回与用户相关的其他时区匹配的事件(例如本地时间)。如果执行此操作,则应以匹配的时区显示事件日期,尤其是在突出显示匹配文本时。
在这里,我给出了最佳可用性的建议,而不会过多地关注实现可行性。
1.对于将事件存储在数据库中的第一期,每个人都同意将其存储在UTC
中2.为了提供最佳的用户体验,请保存用户的时区历史记录。如果您可以保存时区更改的时间戳,那就更好了。这将使我们能够让用户自由查询,而无需每次都明确指定时区。
所以有了这些功能,让我们看看搜索查询只是"9.00"是如何通过 约翰将被处理:
有了上述功能,现在我知道了 到目前为止,约翰一直在 2 个时区(或获取时区列表 提到的时期)。所以我会从悉尼时区到 UTC 的 9.00, 触发查询。同时将 9.00 从纽约时区转换为 UTC,触发 查询。结果,我将向 John 显示 2 行,显示他在 悉尼9.00,纽约9.00。在这种情况下,纽约线将是空白的,但我认为仍然应该向用户显示,只是为了告知 他也搜索了这个时区。
3.向用户询问可能包含时区的时间戳的好方法是什么?
如果他的时区最近更改,每当他登录应用程序时, 应发出通知,说明您的默认时区已更改 到本地时区。
在创建事件时,假设用户选择 时区从下拉菜单。让我们不要通过提供所有选项来给用户带来负担 世界时区。下拉列表的第一个选项应为当前时间 用户设备的区域。在那之后,他的历史中的时区 时区,然后是UTC,然后是他从未有过的时区 使用至今。
4.如果来自世界各地的团队需要讨论事件,如何显示结果:
我想将此用例划分为2个或更多团队的数量 比 2.
对于只有 2 个团队,我希望每个团队都看到 其本地时区和其他团队的时区的时间戳。(一 个人更喜欢在另一端的人的时区交谈,因为他 安排会议时的便利性)。对于超过 2 个团队,其 最好考虑更常见的时区,即UTC。所以在这种情况下,每个 用户应看到 2 个时区的时间戳,UTC 和默认值 时区。
给出这些建议的目的是让用户不需要在他的当地时间进行任何计算,但同时他应该能够在他们喜欢的时区与其他用户流利地通信。
我得到了与其他人不同的方法:
首先,我事先假设了几件事。
列出事件的人拥有智能手机(如果是浏览器,我不必做出这些假设):
全球定位系统
HTML5 功能。
Javascript 功能
我应该如何在数据库中保存时间戳?
解决方案:显然是UTC,我在下面覆盖了过程:
第 1 步。使用地理位置 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)作为参数提供给一些(纬度,经度)到时区的api,例如Yahoo API(使用Flag R将纬度转换为时区)以获取用户时区。
=> 用户时区是在没有用户输入的情况下确定的(我正在使用这个是因为你不能简单地假设用户知道他居住的地方的时区,我只是在几个月后才知道我的时区,或者在那个地方:P,很愚蠢!
每个事件表都有Timezone
,Event
等也可以有CityName
然后创建另一个数据库表,其分类基于 CityName
s。所以这里的用户将有两列
|---------------------------------------|
|_____NewYork________|______Sydney______|
| | |
|Event 1 | Event 2 |
|____________________|__________________|
对于用户界面
=> 使用 Google 日历 API 或某些日历 API
相关阅读材料:
根据纬度/经度确定时区,而无需使用 Geonames.org 等 Web 服务
从纬度经度查找时区
我知道这只是为了展示一些如何解决这个问题的想法。但是,看看当使用设备API确定时区时,它对用户的准确性和轻量级程度
希望对您有所帮助!
对于这种特殊情况,我会存储本地和 UTC 时间。UTC是一个有点重要的,用于将时间同步和转换为当前时区。本地用于搜索和其他信息,例如:
您有一个会议:
12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)
或类似的东西。另一种方法是存储创建时区,并在运行时进行转换(如果用户更改会议时间,这尤其好)。无论哪种方式,主要原因是能够恢复原始创建时间,以便用户可以参考它。
- 我应该如何在数据库中保存时间戳
在创建事件时,我会存储 UTC 时间和本地时区(又名 creation time zone
)。我会使用我存储的内容将 UTC 时间转换为本地时间(又名 creation time
),并将其与 UTC 时间和 creation time zone
一起存储。
注意:我可以从一开始就存储本地时间,但是当用户搜索事件时,我希望存在转换为本地时间。我还希望服务器可以检测到客户端在哪个时区。
- 我应该如何在 UI 中呈现它们
当用户搜索"9:00"时,我会搜索 UTC 或 creation time
OR 本地时间中包含"9:00"的事件。对于结果,我将在creation time
中显示一个结果表(这旨在显示可能已在不同时区创建的时间戳,因为我们假设用户正在寻找他为任何地方创建事件的时间),并在下面显示第二个结果表和相关结果, 也许带有标题,"不是你要找的?请参阅相关结果"(其中包括剩余的 UTC 和本地时间结果)。
总的来说,我会显示 UTC 时间、本地时间、creation time
和按 UTC 时间排序的creation time zone
(即创建它的事件的本地时间和时区),这样您就可以看到哪个事件先出现,以防两个不同的事件安排在两个不同时区的 9:00。