我正在使用Google Directions API开发一个交通导航应用程序。
departure_timeAPI 要求我为公交查询提交出发时间 ( )。
此参数是否需要将本地时间转换为UTC时间？
我无法通过 API 的响应对其进行验证，因为其中没有返回准确的时间。
问问题
2064 次
1 回答
1
那个文件有误
显然，编写该文档页面的 Google 团队犯了一个错误，后来修复了它。
您举报的号码1343605500不再出现在该页面上。今天那页上的数字是1343641500。我怀疑您之前确实在该页面上看到了该号码。谷歌搜索（具有讽刺意味的是）site:https://developers.google.com 1343605500确实将该页面列为热门。显然，命中是基于旧错误页面的缓存副本。即使是谷歌也无法逃脱谷歌的影响。
在 UTC/GMT 工作
此参数是否需要将本地时间转换为UTC时间？
是的。
该 API 适用于 GMT/UTC（无时区偏移），这仅在您考虑时才有意义。几乎总是，处理日期时间的最佳实践是在UTC中执行您的业务逻辑、序列化、数据库记录等，然后转换为本地时间仅用于呈现给用户。
仅查看示例 URL 本身就表明它是 UTC 格式的。对本地时区的唯一可能引用是“布鲁克林”这个词，它肯定不是一个明确的时区唯一标识符。
当然，文档说 API 使用 UTC/GMT：
自 UTC 时间 1970 年 1 月 1 日午夜以来的所需出发时间（以秒为单位）
写得不好
混乱源于该文档页面中的糟糕文字。他们需要在“9:45 am”后面加上一个重要的“UTC”或“GMT”。同时提及纽约和 9:45 意味着当地时间，而该示例实际上是布鲁克林当地时间早上 5:45。
以下请求搜索从纽约布鲁克林到纽约皇后区的公交路线。请求公交路线时，请务必指定出发时间或到达时间。
请注意，在此示例中，出发时间指定为 2012 年 7 月 30 日上午 09:45。在提交请求之前将参数更新为将来的某个时间点。
旧数字与新数字
旧号码：1343605500（由 davidg和谷歌搜索在答案中报告）
新号码：1343641500（2013-12发现）
如果他们在纽约实际上是指 9:45 的数字：1343655900。
示例代码
我不做 JavaScript。因此，我使用在 Java 7 中运行的复杂的Joda-Time 2.3 日期时间处理库来展示一些 Java 代码。我同时使用旧（错误）和新（正确）数字来显示 UTC 和新的日期时间约克时区。此外，我计算了从 epoch 到纽约 2012 年 7 月 30 日上午 9:45 的秒数，以产生第三个秒数。
Google API 使用秒，而 Joda-Time 使用毫秒，所以我乘以或除以一千。
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
// import org.joda.time.*;
DateTimeZone timeZone_NewYork = DateTimeZone.forID( "America/New_York" );
// On this page:
// https://developers.google.com/maps/documentation/directions/#ExampleRequests
// …look for the following two paragraphs…
// --
// The below request searches for Transit Directions from Brooklyn, New York to Queens, New York. When requesting transit directions, be sure to specify either a departure_time or arrival_time.
// Note that in this example the departure time is specified as July 30, 2012 at 09:45 am. Update the parameter to a point in the future before submitting the request.
// --
// Below that text, find this URL:
// http://maps.googleapis.com/maps/api/directions/json?origin=Brooklyn&destination=Queens&sensor=false&departure_time=1343641500&mode=transit
// Extract that departure time of 1,343,641,500 seconds since the Unix Epoch of beginning of 1970 UTC.
// Apparently in the past that page erroneously used the number 1343605500 where today it uses 1343641500.
// Use the correct number found on that page today, 2013-12-25: 1343641500.
DateTime dateTimeInUtcWithNewNumber = new DateTime ( ( 1343641500L * 1000L ), DateTimeZone.UTC );
DateTime dateTimeInNewYorkWithNewNumber = dateTimeInUtcWithNewNumber.toDateTime( timeZone_NewYork );
System.out.println( "dateTimeInUtcWithNewNumber: " + dateTimeInUtcWithNewNumber );
System.out.println( "dateTimeInNewYorkWithNewNumber: " + dateTimeInNewYorkWithNewNumber );
// Use the old erroneous number previously found on that page: 1343605500.
DateTime dateTimeInUtcWithOldNumber = new DateTime ( ( 1343605500L * 1000L ), DateTimeZone.UTC );
DateTime dateTimeInNewYorkWithOldNumber = dateTimeInUtcWithOldNumber.toDateTime( timeZone_NewYork );
System.out.println( "dateTimeInUtcWithOldNumber: " + dateTimeInUtcWithOldNumber );
System.out.println( "dateTimeInNewYorkWithOldNumber: " + dateTimeInNewYorkWithOldNumber );
// Calculating the number that should have been used if the Google team had actually meant 9:45 AM local time in New York: 1343655900.
DateTime dateTimeInNewYork_2012_07_30_09_45 = new DateTime ( 2012, 7, 30, 9, 45, 0, timeZone_NewYork );
System.out.println( "dateTimeInNewYork_2012_07_30_09_45: " + dateTimeInNewYork_2012_07_30_09_45 );
System.out.println( "dateTimeInNewYork_2012_07_30_09_45 in seconds since Unix epoch: " + ( dateTimeInNewYork_2012_07_30_09_45.getMillis() / 1000L ) );
运行时……</p>
dateTimeInUtcWithNewNumber: 2012-07-30T09:45:00.000Z
dateTimeInNewYorkWithNewNumber: 2012-07-30T05:45:00.000-04:00
dateTimeInUtcWithOldNumber: 2012-07-29T23:45:00.000Z
dateTimeInNewYorkWithOldNumber: 2012-07-29T19:45:00.000-04:00
dateTimeInNewYork_2012_07_30_09_45: 2012-07-30T09:45:00.000-04:00
dateTimeInNewYork_2012_07_30_09_45 in seconds since Unix epoch: 1343655900
于 2013-12-25T19:34:24.707 回答