Google Directions API是使用UTC还是本地时间?

时间:2012-09-20 15:07:22

标签: google-maps

我正在使用Google Directions API开发一个公交导航应用。

API要求我为过境查询提交出发时间(departure_time)。

是否有必要将此参数的本地时间转换为UTC时间?

我无法通过API的响应验证它,因为它没有返回准确的时间。

1 个答案:

答案 0 :(得分:1)

该文档出错

显然,Google团队撰写that doc page时出错并稍后修复。

在该页面上找不到您报告的号码1343605500。今天该页面上的数字是1343641500。我怀疑你之前确实在该页面上看到了这个号码。谷歌搜索(具有讽刺意味的是)site:https://developers.google.com 1343605500确实将该页面列为命中。显然,点击是基于旧错误页面的缓存副本。即便谷歌也无法逃脱谷歌的影响。

以UTC / GMT工作

  

是否有必要将此参数的本地时间转换为UTC时间?

API使用GMT / UTC(没有时区偏移),只有在您考虑时才有意义。几乎总是,处理日期时间的最佳做法是在UTC中执行业务逻辑,序列化,数据库记录等,然后仅转换为本地时间以便呈现给用户。

仅查看示例网址本身就表明它是UTC格式。对本地时区唯一可能的引用是“布鲁克林”这个词,它当然不是时区的唯一标识符。

  

http://maps.googleapis.com/maps/api/directions/json?origin=Brooklyn&destination=Queens&sensor=false&departure_time=1343641500&mode=transit

当然,文档说API使用UTC / GMT:

  

所需的出发时间为UTC时间1970年1月1日午夜以来的秒数

写作不好

混淆源于documentation page中写得不好的人。他们需要在“上午9:45”附加关键的“UTC”或“GMT”。提及纽约和9:45相同的呼吸意味着当地时间,而那个例子在布鲁克林当地时间早上是5:45。

  

以下请求搜索从纽约布鲁克林到纽约皇后区的公交路线。在请求公交路线时,请务必指定departure_time或arrival_time。

     

请注意,在此示例中,出发时间指定为2012年7月30日上午09:45。在提交请求之前,将参数更新为将来的某个点。

旧与新数字

旧号码:1343605500(在answer by davidg中报告,并通过Google搜索)

新号码:1343641500(找到2013-12)

如果他们在纽约实际意味着9:45:1343655900。

示例代码

我不做JavaScript。因此,我使用在Java 7中运行的复杂Joda-Time 2。3日期时间处理库来呈现一些Java代码。我使用旧的(错误的)和新的(正确的)数字来显示两个UTC中的日期时间和纽约时区。此外,我计算了自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 ) );

跑步时......

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