I have this timezone result from google map, for instance,
{
"dstOffset" : 0.0,
"rawOffset" : -28800.0,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Standard Time"
}
which one is local time and which one is utc time?
dstOffset: the offset for daylight-savings time in seconds. This will be zero if the time zone is not in Daylight Savings Time during the specified timestamp.
rawOffset: the offset from UTC (in seconds) for the given location. This does not take into effect daylight savings.
Calculating the Local Time:
The local time of a given location is the sum of the timestamp parameter, and the dstOffset and rawOffset fields from the result.
The Google Time zone API
Related
I have exported data from a health app showing my weight that I tracked over the last few years. The app no longer has this functionality so the only way for me to get this data is to read the JSON file and put it into another app. I understand the weight part, as it is KG, instead of LB. I just need help understanding the "Created_at" so I know what date this is from. Is there an easier way to translate this part of the JSON? Based on the timezone offset, it looks like it is in seconds, but that's all I have figured out so far. Any help would be greatly appreciated.
{
"start_time": 1517323800000,
"created_at": 1517323824000,
"updated_at": 1517323824000,
"start_time_timezone_offset": -22000,
"weight": 73.84483783600001,
"origin_type": "manual",
"id": "d1640b9b-c8bd-6b54-5a3c-da492e8ac75a"
}
Milliseconds to date converter helps you to find the date and time from a given total number of milliseconds. This total number of milliseconds is the elapsed milliseconds since timestamp or unix epoch counting from 1 January 1970.
for example: 1517323800000 is Tue 30 January 2018
16:50:00
https://www.timecalculator.net/milliseconds-to-date
I am collecting ETA for few locations for some project work. I get different time duration during different point of time, but there is one case which returns same results
Origin: Acres Club, 411-B, Hemu Kalani Marg, Sindhi Society, Chembur, Mumbai, Maharashtra
Destination: Chhatrapati Shivaji Terminus, Chhatrapati Shivaji Terminus Area, Mumbai, Maharashtra
This always returns 1702 seconds.
Below is the API call I am making:
https://maps.googleapis.com/maps/api/distancematrix/json?origins=Acres%20Club,%20411-B,%20Hemu%20Kalani%20Marg,%20Sindhi%20Society,%20Chembur,%20Mumbai,%20Maharashtra&destinations=Chhatrapati%20Shivaji%20Terminus,%20Chhatrapati%20Shivaji%20Terminus%20Area,%20Mumbai,%20Maharashtra&key=
Let me know if I am missing anything. Thanks in Aadvance.
If I understand correctly you are interested in getting a duration taking into account current traffic conditions. Please note that duration with traffic conditions requires a departure time to be specified in your request.
Have a look at the documentation that reads:
departure_time — The desired time of departure. You can specify the time as an integer in seconds since midnight, January 1, 1970 UTC. Alternatively, you can specify a value of now, which sets the departure time to the current time (correct to the nearest second).
For requests where the travel mode is driving: You can specify the departure_time to receive a route and trip duration (response field: duration_in_traffic) that take traffic conditions into account. This option is only available if the request contains a valid API key, or a valid Google Maps APIs Premium Plan client ID and signature. The departure_time must be set to the current time or some time in the future. It cannot be in the past.
https://developers.google.com/maps/documentation/distance-matrix/intro#DistanceMatrixRequests
I would suggest changing you request to
https://maps.googleapis.com/maps/api/distancematrix/json?origins=Acres%20Club%2C%20411-B%2C%20Hemu%20Kalani%20Marg%2C%20Sindhi%20Society%2C%20Chembur%2C%20Mumbai%2C%20Maharashtra&destinations=Chhatrapati%20Shivaji%20Terminus%2C%20Chhatrapati%20Shivaji%20Terminus%20Area%2C%20Mumbai&departure_time=now&traffic_model=best_guess&key=YOUR_API_KEY
In this case you will see something similar to
"rows":[
{
"elements":[
{
"distance":{
"text":"16.2 km",
"value":16206
},
"duration":{
"text":"28 mins",
"value":1702
},
"duration_in_traffic":{
"text":"45 mins",
"value":2715
},
"status":"OK"
}
]
}
],
in your response. Where duration_in_traffic shows duration taking into account current traffic conditions and duration is a typical average duration.
Hope this helps!
I am using the HighStock API of HighChart.
The demo:
http://jsfiddle.net/gh/get/jquery/1.9.1/highslide-software/highcharts.com/tree/master/samples/stock/demo/compare/
Makes a timeline on the x-Axis.
But the data JSON data for the graph has the following keys:
E.g. for AAPL:
?(/* AAPL historical OHLC data from the Google Finance API */
[
/* Dec 2008 */
[1229472000000,12.74],
[1229558400000,12.78],
[1229644800000,12.86],
[1229904000000,12.25],
[1229990400000,12.34],
[1230076800000,12.15],
[1230249600000,12.26],
[1230508800000,12.37],
[1230595200000,12.33],
[1230681600000,12.19],
How do all the 1229.... values relate to Date/Time?? I mean how does
1232582400000
relate to 22. January 2009???
And I have data int he following format in Java:
2015-12-10 15:27
How should I use them in the HighChart API?
The numeric time stamps you see as "1232582400000" is the javascript time stamp. I believe it is UNIX epoch time in milliseconds (multiply epoch time by 1000). You can convert your human-readable time values into javascript time in any number of ways. The basic example if you have year, month, day, hour, and second would be to make your data series use Date.UTC():
[Date.UTC(year, month, day, hour, minute), yValue]
"Unix time (also known as POSIX time or Epoch time) is a system for
describing instants in time, defined as the number of seconds that
have elapsed since 00:00:00 Coordinated Universal Time (UTC),
Thursday, 1 January 1970, not counting leap seconds."
(source)
I want to get tcpdump at low time resolution (at milliseconds) instead of default microseconds.
in tcpdump manual I got -j argument with acceptable precisions as 'host_lowprec' and 'host_hiprec'
tcpdump -i any -n -j host_lowprec "tcp"
I have 2 questions:
host_lowprec = ? precision
and
host_hiprec = ? precision
can I set precision to milliseconds or nanoseconds ? if yes how?
In answer to your first question:
The tcpdump man page says of the -j option:
-j tstamp_type
--time-stamp-type=tstamp_type
Set the time stamp type for the capture to tstamp_type. The names to use for the time stamp types are given in pcap-tstamp(7); not all the types listed there will necessarily be valid for any given interface.
and the pcap-tstamp(7) man page says:
... The time stamp types are listed here; the first value is the #define to use in code, the second value is the value returned by pcap_tstamp_type_val_to_name() and accepted by pcap_tstamp_type_name_to_val().
PCAP_TSTAMP_HOST - host
Time stamp provided by the host on which the capture is being done. The precision of this time stamp is unspecified; it might or might not be synchronized with the host operating system's clock.
PCAP_TSTAMP_HOST_LOWPREC - host_lowprec
Time stamp provided by the host on which the capture is being done. This is a low-precision time stamp, synchronized with the host operating system's clock.
PCAP_TSTAMP_HOST_HIPREC - host_hiprec
Time stamp provided by the host on which the capture is being done. This is a high-precision time stamp; it might or might not be synchronized with the host operating system's clock. It might be more expensive to fetch than PCAP_TSTAMP_HOST_LOWPREC.
PCAP_TSTAMP_ADAPTER - adapter
Time stamp provided by the network adapter on which the capture is being done. This is a high-precision time stamp, synchronized with the host operating system's clock.
PCAP_TSTAMP_ADAPTER_UNSYNCED - adapter_unsynced
Time stamp provided by the network adapter on which the capture is being done. This is a high-precision time stamp; it is not synchronized with the host operating system's clock.
Neither host_lowprec nor host_hiprec specify an exact precision. The precision set with -j does NOT affect the way time stamps are stored in a capture file; they will be stored as seconds and microseconds, unless you have a newer version of tcpdump that supports the --time-stamp-precision option and the OS can deliver nanosecond time stamps, in which case they will be stored as seconds and nanoseconds and the file will have a different "magic number" so that tcpdump/Wireshark/etc. can read the time stamps properly.
All the -j option controls is how much of the microseconds (or nanoseconds) value is significant.
In answer to your second question:
There is no mechanism for storing times in pcap files as seconds and milliseconds, and there's no explicit option to request that the microseconds (or nanoseconds) value have only 3 significant figures.
There is an option to request that the time stamps be stored as seconds and nanoseconds. If you are doing a live capture, this will work only if the operating system supports delivering seconds and nanoseconds time stamps when capturing; this currently only works on newer versions of Linux.
What is it that you are trying to accomplish here?
I am developing a transit navigation app using the Google Directions API.
The API requires me to submit a departure time (departure_time) for transit queries.
Is it necessary to convert the local time to UTC time for this parameter?
I could not validate it through the API's response, as there is no accurate time returned in it.
That Doc Was In Error
Apparently the Google team writing that doc page made an error and later fixed it.
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.
Work in UTC/GMT
Is it necessary to convert the local time to UTC time for this parameter?
Yes.
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.
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.
http://maps.googleapis.com/maps/api/directions/json?origin=Brooklyn&destination=Queens&sensor=false&departure_time=1343641500&mode=transit
And of course the doc says the API uses UTC/GMT:
the desired time of departure as seconds since midnight, January 1, 1970 UTC
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.
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.
Old Versus New Numbers
Old number: 1343605500 (reported in the answer by davidg, and by googling)
New number: 1343641500 (found 2013-12)
Number if they had actually meant 9:45 in New York: 1343655900.
Example Code
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.
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 ) );
When run…
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