我正在使用Google Directions API开发一个公交导航应用。
API要求我为过境查询提交出发时间(departure_time
)。
是否有必要将此参数的本地时间转换为UTC时间?
我无法通过API的响应验证它,因为它没有返回准确的时间。
答案 0 :(得分:1)
显然,Google团队撰写that doc page时出错并稍后修复。
在该页面上找不到您报告的号码1343605500
。今天该页面上的数字是1343641500
。我怀疑你之前确实在该页面上看到了这个号码。谷歌搜索(具有讽刺意味的是)site:https://developers.google.com 1343605500
确实将该页面列为命中。显然,点击是基于旧错误页面的缓存副本。即便谷歌也无法逃脱谷歌的影响。
是否有必要将此参数的本地时间转换为UTC时间?
是
API使用GMT / UTC(没有时区偏移),只有在您考虑时才有意义。几乎总是,处理日期时间的最佳做法是在UTC中执行业务逻辑,序列化,数据库记录等,然后仅转换为本地时间以便呈现给用户。
仅查看示例网址本身就表明它是UTC格式。对本地时区唯一可能的引用是“布鲁克林”这个词,它当然不是时区的唯一标识符。
当然,文档说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