Google Directions API是否使用UTC或本地时间? [英] Does the Google Directions API use UTC or Local Time?
问题描述
我正在使用 Google Directions API 开发公交导航应用.
I am developing a transit navigation app using the Google Directions API.
API要求我提交公交查询的出发时间(departure_time).
The API requires me to submit a departure time (departure_time) for transit queries.
是否需要为此参数将本地时间转换为UTC时间?
Is it necessary to convert the local time to UTC time for this parameter?
我无法通过API的响应对其进行验证，因为其中没有返回准确的时间.
I could not validate it through the API's response, as there is no accurate time returned in it.
推荐答案
该文档有误
显然Google团队写了该文档页面，并且以后修复它.
That Doc Was In Error
Apparently the Google team writing that doc page made an error and later fixed it.
您报告的电话号码1343605500不再在该页面上找到.今天，该页面上的数字是1343641500.我怀疑您以前确实在该页面上看到过该号码.对site:https://developers.google.com 1343605500进行谷歌搜索(具有讽刺意味的是)确实将该页面列为匹配项.显然，匹配是基于旧错误页面的缓存副本.甚至Google也无法逃脱Google的影响力.
The number you report 1343605500 is no longer found on that page. Today the number on that page is 1343641500. I suspect you did indeed see that number on that page previously. Googling (ironically enough) for site:https://developers.google.com 1343605500 does list that page as a hit. Apparently the hit is based on a cached copy of the old erroneous page. Even Google cannot escape the reach of Google.
是否需要为此参数将本地时间转换为UTC时间?
Is it necessary to convert the local time to UTC time for this parameter?
是的
API与GMT/UTC配合使用(无时区偏移)，仅在您考虑时才有意义.几乎总是，处理日期时间的最佳实践是在
The API works with GMT/UTC (no time zone offset), which only makes sense when you think about it. Almost always, the best practice for handling date-time is to perform your business logic, serialization, database records, and so on in UTC, then convert to local time only for presentation to the user.
仅查看示例URL本身就表明它位于UTC中.对本地时区的唯一可能参考是单词"Brooklyn".当然，这不是一个明确的时区唯一标识符.
Just looking at the example URL itself suggests it is in UTC. The only possible reference to a local time zone would be the word "Brooklyn" which is certainly not a clear unique identifier for a time zone.
And of course the doc says the API uses UTC/GMT:
期望的出发时间，以世界标准时间1970年1月1日午夜开始的秒数
the desired time of departure as seconds since midnight, January 1, 1970 UTC
写作不佳
混乱的原因在于文档页面上的拙劣写作.他们需要附加关键的"UTC".或"GMT"到上午9:45".同时提及纽约和9:45表示本地时间，而该示例确实是布鲁克林当地时间早上5:45.
Poor Writing
The confusion stems from the poor writing in that documentation page. They need to append a crucial "UTC" or "GMT" to that "9:45 am". Mentioning New York and 9:45 in the same breath implies local time, whereas that example is truly 5:45 in the morning local time in Brooklyn.
以下请求搜索从纽约布鲁克林到纽约皇后区的公交路线.请求运输路线时，请确保指定出发时间"或到达时间".
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.
请注意，在本示例中，出发时间指定为2012年7月30日上午09:45.提交请求之前，请将参数更新到将来的某个点.
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.
旧数字与新数字
旧电话号码:1343605500(在 davidg 并通过谷歌搜索得到的答案中报告)
Old Versus New Numbers
Old number: 1343605500 (reported in the answer by davidg, and by googling)
新电话号码:1343641500(发现于2013-12年)
New number: 1343641500 (found 2013-12)
如果他们实际上在纽约表示9:45的数字:1343655900.
Number if they had actually meant 9:45 in New York: 1343655900.
我不使用JavaScript.因此，我改为使用复杂的 Joda-Time 2.3日期时间显示一些Java代码.处理在Java 7中运行的库.我同时使用旧的(错误的)和新的(正确的)数字来显示UTC和纽约时区的日期时间.此外，我计算了从纪元到2012年7月30日上午9:45在纽约产生第三秒数以来的秒数.
I don't do JavaScript. So instead, I present some Java code using the sophisticated Joda-Time 2.3 date-time handling library running in Java 7. I use both the old (erroneous) and new (correct) numbers to show the date-time in both UTC and New York time zones. Furthermore, I calculate the number of seconds since epoch would have been used to get to 9:45 am July 30 2012 in New York, to produce a third number of seconds.
Google API使用秒，而Joda-Time使用毫秒，所以我乘或除以一千.
The Google API uses seconds, while Joda-Time uses milliseconds, so I multiply or divide by a thousand.
// © 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这篇关于Google Directions API是否使用UTC或本地时间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
