我目前正在以UTC时间存储某些实体的事件，但我不确定在这种情况下是否应该这样做。想象一下，当地时间晚上10点（UTC时间-4点）有一个活动，移动应用程序会提取＆＃34; 今天的事件＆＃34;。这可以是例如看起来像这样：
从俱乐部获取所有活动并使用当地时间偏移信息将它们转换为当地时间并不是一个很好的解决方案。
那么在当地时间存储所有活动会不会更好？在这种情况下，移动应用程序会将其本地时间发送到服务器，该服务器也能够在当地时间查询来自俱乐部的所有事件。
这对我来说听起来简单得多，但我不确定我是否会忽视某些事情。
那么在这种情况下我该怎么做？
答案 0 :(得分：1)
是的，以UTC格式存储所有内容可能是最佳解决方案。
您没有说明如何“存储”日期/时间，但如果您使用Dates或Joda等价物，那么您应该知道它们的基础表示实际上是UTC（它们代表一个时刻作为自“Epoch”以来，以毫秒为单位的偏移量，即1970年1月1日午夜的UTC。当您将它们格式化为字符串时，这些日期只有一个时区。
大多数数据库都做类似的事情（将日期存储在一个公共时区，通常是UTC）。我发现的一个主要例外是MS SqlServer中通常可用的与日期时间相关的列类型，它默认将所有内容存储在服务器的本地时区。
另请注意，如果您使用SQLite，并通过在包含时区的SQL中传递String来存储日期/时间，SQLite将在不发出警告的情况下存储它，但会忽略时区并假设时区为UTC，给你的结果不是你所期望的。
上的（旧）博客文章答案 1 :(得分：0)
另一个答案是正确的。还有一些想法。
时区大于问题中提到的UTC的偏移量。时区也是夏令时等异常的过去，现在和未来规则的集合。您应该按proper name，大陆加斜线加城市或地区来引用时区。切勿使用EST或IST等3-4字母代码。
要搜索用户“今天”中的事件，您必须知道用户的时区。例如，巴黎的新日早些时候比蒙特利尔早。在巴黎午夜过后，我们仍然有几个小时的“昨天”留在蒙特利尔。
虽然您可以猜测用户的时区，但最可靠的方法是询问用户。
DateTimeZone zone = DateTimeZone.forID( "America/Montreal" );
DateTimeZone now = DateTimeZone.now( zone );
DateTime today = now.withTimeAtStartOfDay();
DateTime tomorrow = today.plusDays( 1 );
// Search for events that start >= today AND that start < tomorrow.
要搜索Joda-Time对象，请使用DateTime中内置的比较器。该比较器适用于不同时区的对象。
要查询数据库，请将该对DateTime对象转换为java.sql.Timestamp个对象。您可以通过extracting执行此操作，并将自1970年代以来的毫秒数传递给UTC。
long m = today.getMillis();
java.sql.Timestamp tsToday = new java.sql.Timestamp( m );