when you set departureTime param for your isoline calculations,
the departure time is the local time, but which local time ?
The local time of the location departure point, the local time of my
web server location ?
Is it possible to be more accurate ?
Thanks in advance
The following statement in your original question is not accurate:
the departure time is the local time
The Isoline Routing API v8 uses RFC 3339 for the departureTime parameter, so the departure time can be any time and any timezone you want, it doesn't have to be "local".
According to the API documentation, the requested time is converted to the local time at destination. In your case, this means that no matter what time and timezone you use, the service will always adjust it to the time of the city where your coordinates are (origin or destination parameter). Let me give you a few examples:
Example 1: Different timezones
Consider the following request where the coordinates in the origin parameter are in Berlin, Germany:
https://isoline.router.hereapi.com/v8/isolines?
apikey=************&
origin=52.525927,13.388686&
departureTime=2022-01-05T10:00:00-06:00&
range[type]=time&
range[values]=600&
transportMode=car
The timezone offset in the request is -06:00, and it's +01:00 at the origin coordinates (Berlin), so the service converts the input time and uses 2022-01-05T17:00:00+01:00 for the isoline calculation.
Example 2: Same timezone
https://isoline.router.hereapi.com/v8/isolines?
apikey=************&
origin=52.525927,13.388686&
departureTime=2022-01-05T10:00:00+01:00&
range[type]=time&
range[values]=600&
transportMode=car
Since the timezone offset in the request (+01:00) is the same as the timezome at our coordinates location, the service will use the same timestamp for the isoline calculation: 2022-01-05T10:00:00+01:00.
Example 3: Unspecified timezone offset
https://isoline.router.hereapi.com/v8/isolines?
apikey=************&
origin=52.525927,13.388686&
departureTime=2022-01-05T10:00:00&
range[type]=time&
range[values]=600&
transportMode=car
According to the API documentation, when the timezone offset is not specified, the time is assumed to be local. Since we're still using those coordinates located in Berlin, "local" here means UTC +01:00, so the service uses 2022-01-05T10:00:00+01:00 for the isoline calculation.
Example 4: The "Z" suffix
https://isoline.router.hereapi.com/v8/isolines?
apikey=************&
origin=52.525927,13.388686&
departureTime=2022-01-05T10:00:00Z&
range[type]=time&
range[values]=600&
transportMode=car
In RFC 3339, the "Z" suffix denotes denotes a UTC offset of 00:00. In this scenario, the service uses 2022-01-05T11:00:00+01:00 for the isoline calculation.
Related
my backend server stores a utc timestamp with python and send it to frontend.
from datetime import datetime
utcTs = datetime.utcnow().timestamp()
and then frontend app (node.js) get the utcTs , convert it to locale time (or custom timezone)
I code like this:
moment.unix(utcTs).add(8,'hour').format()
because the utcTs is a utc+0 timestamp, how can I initialize a moment object as utc+0, so I can convert it to other timezone easily.
for example, my locale is utc+8.
moment.tz(utcTs,'Asia/Shanghai').format()
return a incorrect time.
is there any gentle way? thanks
The timestamp returned from Python's timestamp() method is in terms of UTC-based seconds from the Unix epoch, so you just need to do the same thing in Moment.
// this is in seconds, but creates a moment in local mode
moment.unix(utcTs).add(8,'hour').format()
// you need to get it in UTC mode with the .utc(). Adding gives a moment 8 hours later.
moment.unix(utcTs).utc().add(8,'hour').format()
// this is how you get it in a fixed offset instead of adding
moment.unix(utcTs).utcOffset('+08:00').format()
Since not all time zones can use fixed offsets, the following is a better approach.
// this is incorrect, as the input would interpreted as milliseconds
moment.tz(utcTs,'Asia/Shanghai').format()
// this is the correct way for it interpreted in terms of seconds
moment.unix(utcTs).tz('Asia/Shanghai').format()
I was using TransportAPI to request a public route that took place at a specified date and time.
But it didnt return any route data. How should I set the date and time?
There's two different TransportAPI endpoints which you might be referring to when you say "public route" here. In both cases you can add date and time to the query:
You might mean "bus/route" - bus timetable information about one particular route. You actually have to specify a bus route (operator and line name) and details of particular departure, so for example here is the 185 bus departure at 11:26 today towards Lewisham:
http://transportapi.com/v3/uk/bus/route/LONDONBUS/185/inbound/490012571T/2017-09-22/11:26/timetable.json?app_id=APP_ID&app_key=APP_KEY
...or you might mean "public/journey". A route (or "journey plan") through the public transport system from one location to another. For example here's a journey plan from Vauxhall to Bethnal Green. The response is not just one route, but multiple alternatives
https://transportapi.com/v3/uk/public/journey/from/lonlat:-0.11966,51.48626/to/lonlat:-0.05703,51.52398/at/2017-10-10/10:00.json?
app_id=APP_ID&app_key=APP_KEY
The /at/2017-10-10/10:00 bit specifies your desired departure time, but you can also say /by/2017-10-10/10:00 to specify a desired arrival time, or you can leave it out (then it just plans for departing now)
Is there a definition what values should be send in OData Edm:DateTime of a SAP Netweaver Gateway service?
Especially should it always be interpreted as UTC?
I assume the SAPUI5 library is smart enough to handle all this time zone problems automatically if the interface is correct defined -- question is, what is correct?
I would prefer to use some code like this, at client side:
new sap.m.DatePicker({
value : {
path : "BirthDate",
type : new sap.ui.model.type.Date
}
}),
How do you solve these problems?
Edit
Time zone handling seems still to be strange to me.
SAP Gateway Server sends in an Edm:DateTime following: 2015-04-16T00:00:00
Any time zone information is missing.
If I bind a date picker like this:
var oContent = new sap.m.DatePicker({
value : {
path : "Date",
type : new sap.ui.model.type.Date({
style: "short",
})
}
})
I got the following output: 16.04.15 (seems to be correct).
Binding a date picker without type information shows: Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
If I change the date with the date picker to 17.04.15 the second line is:
Fri Apr 17 2015 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
Please note the difference in time (2 hours missing).
If I send it to the server I got Edm.DateTime == 2015-04-16T00:00:00
Control shows:
Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
If I use
new sap.m.DatePicker({
value : {
path : "Date",
type : new sap.ui.model.type.Date({
style: "short",
UTC: true
})
}
})
Data seems to be correct (the 2 hours are not missing after picking a new date).
I am asking me, is there any definition what type of data gateway will send?
If the timezone is missing inside the Edm.DateTime information how should a client work correct? Especially if clients are in different time zones available?
Strange enough I have a similar problem by using a filter. But there the UTC flag seems not working.
Anyone with some experience on that topic? Or any hints to a good documentation?
* https://sapui5.netweaver.ondemand.com/sdk/#docs/guide/91f3070d6f4d1014b6dd926db0e91070.html
Says more or less "take care" but not how :-/
Further information
I detected the same question on SAP network (http://scn.sap.com/thread/3574419). Not sure if the given answer is correct. Looks like hacking around in meta-data which should not be required?
I am still searching for a solution to this problem
I detected different handling of data in case of binding and filter usage.
I can't answer with regard to SAP, as I am not familiar. But I can provide some insights based on OData.
The Edm:DateTime type is based on the W3C XML Schema xs:dateTime, which is in-turn based on ISO8601. Both XML Schema and ISO8601 state that times without a time zone are to be considered "local time". That is, local to someone. Whose "local" it is intentionally undefined.
From W3C XML Schema §3.2.7:
"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority
From ISO 8601 3rd Edition §4.3.2:
The zone designator is empty if use is made of local time ...
Consider your example of 2015-04-16T00:00:00. The only way to know what exact moment in time this refers to is to have some additional context applied. In the case of a birthday, this could be the time zone where the person is currently located (where they celebrate their birthday, not where they are born). Or, it could be some arbitrary location if the person's location is unknown - perhaps the time zone of the person using the system.
Therefore, the interpretation of the value is where the time zone is being applied. In your case, it would appear that some local time zone is being applied during deserialization.
Also consider that a birthday is better represented by just a calendar date, rather than midnight on a date. The Edm:Date type is better suited for this. For other types, especially if you know that the value is UTC or in a specific time zone, then Edm:DateTimeOffset is more appropriate.
Also recognize that the Edm:DateTime type was dropped from OData spec in version 4.0. Many (including myself) consider this a mistake. I'm not sure if this affects you or not, but you should be aware.
Hope that helps.
Use type sap.ui.model.type.Date({ oFormatOptions:{ style: "short", UTC: true} }) this will retain your date as it is sent by server
Could you try binding the date path to dateValue instead of value.
It should automatically interpret Edm:DateTime.
new sap.m.DatePicker({
dateValue : "{BirthDate}"
})
I am using Moment.js and manipulating a date using moment.hour(xx) moment.minute(xx).
When i console.log the moment i see that the object contains a _d and _i:
the _d contains the correct changed moment.hour() or moment.minute() changes however the _i object contains the original?
k {_isAMomentObject: true, _i: Thu Dec 11 2014 20:34:00 GMT+0200 (South Africa Standard Time), _isUTC: false, _pf: Object, _locale: j…}
_d: Thu Dec 11 2014 14:00:00 GMT+0200
_i: Thu Dec 11 2014 20:34:00 GMT+0200
Could anyone enlighten me?
Pay no attention to those. Use the various output functions, such as .format() instead. See the Moment.js guidance on this topic. In short, all fields that are prefixed with an underscore (_) should be considered off limits.
The moment internals have some quirks due to how the Date object works. All of the functions in the public API take them into account, but you probably don't want to figure them out yourself.
Just to be complete though, I'll elaborate on their purpose:
_i is the input used when create the moment object. It can be a string, a number, an array, or a Date object.
However, if another moment object is passed in, the _i will be copied to that moments _i, and other properties will also be copied over. _i will never be a moment object.
_i can also be undefined, in the case of creating the current moment with moment().
_d is the instance of the Date object that backs the moment object.
If you are in "local mode", then _d will have the same local date and time as the moment object exhibits with the public API. The timestamps returned by getTime or valueOf will also match.
If you are in "UTC mode", then _d will still have the same UTC date and time as the moment object exhibits with the public API. This may be confusing, as you'd need to look at getUTCDate and other UTC-based functions on _d in order to see them match. The timestamps will still match here as well.
If you've changed the time zone offset, with the utcOffset, zone, or tz functions, then the _d value cannot stand alone. It must also consider if _offset is defined. If it is, then the timestamp backing the _d object has to first be adjusted by the amount of the offset. You can see this behavior in the implementation of the valueOf method here.
Also, if you look at the string output of _d when a different offset or time zone has been applied, it will appear that _d is using the local time zone. However, that conversion to local time is simply a side effect of the toString function of the Date object. Moment does not use that result in its functions.
This is the behavior for these two fields as of the current version (2.10.6 as I'm writing this). However, there are other fields as well, and since these are internal fields, it's entirely possible the behavior could change in a future version. In particular, see issue #2616.
As a complement to #Matt's answer:
Checkout this result from the chrome's console:
date1 is a moment's valid object:
As you can see, ._d and ._i have different values. So you better use the format() function (as #Matt Johnson wrote) inside your source code.
I am trying to get the travel time with traffic between 2 sets of lat/long coordinates. I can call the Google Distance Matrix API, but I am only getting travel time without traffic. The API notes which I have read say to use a parameter called departure_time. Here is the excerpt:
departure_time specifies the desired time of departure as seconds since midnight, January 1, 1970 UTC. The departure time may be specified by Maps for Business customers for to specify the departure_time to receive trip duration considering current traffic conditions. The departure_time must be set to within a few minutes of the current time.
I found this website to give me that time: epochconverter
However I am still getting the same travel time every time. Here is a sample request, the departure_time parameter would need to be updated (not that it matters).
https://maps.googleapis.com/maps/api/distancematrix/xml?units=imperial&departure_time=1408046331&origins=37.407585,-122.145287&destinations=37.482890,-122.150235
15 minutes is always returned.
Using "maps dot google dot com" a travel time of 19 mins is returned when traffic is taken into account.
If anyone can help me get the travel time with traffic from the Distance Matrix API, that would be greatly appreciated.
No need for business license, just need an API key from project on https://console.developers.google.com/ with Google distance Matrix enabled.
For results as on google map use traffic_model with values pessimistic,optimistic and do keep in mind "The departure_time must be set to within a few minutes of the current time" without that it will always return 15 minutes.
That feature appears to only be available to Maps for Business customers, according to the docs.
Even with business licence you can only query departure_time 5 minutes from now if you're using traveling mode is driving
https://developers.google.com/maps/documentation/distancematrix/
According to the google docs "departure_time" can only be used if "mode"(travel mode) is set to "Driving"(which is the default travelMode) and an Api KEY is included in your request.
There is also an optional parameter "trafficModel".
Here is an example url with proper parameters.
https://maps.googleapis.com/maps/api/distancematrix/json?units=imperial&origins=40.6655101,-73.89188969999998&destinations=40.598566%2C-73.7527626&mode=driving&departure_time=now&traffic_model=optimistic&key=YOUR_API_KEY
To use distance matrix api as javascript code use it as mentioned in this doc.
https://developers.google.com/maps/documentation/javascript/distancematrix
**Imp:**There are many limitations with this API. Most of the features are available only for premium users.Read the above doc carefully.
Please try with below code.
var origin = new google.maps.LatLng(detectedLatitude,detectedLongitude);
var destination = new google.maps.LatLng(latitudeVal,langtitudeVal);
var service = new google.maps.DistanceMatrixService();var date = new Date();
date.setDate(date.getDate() + 1);
var DrivingOptions = {
departureTime: date,
trafficModel: 'pessimistic'
};
service.getDistanceMatrix(
{
origins: [origin],
destinations: [destination],
travelMode: 'DRIVING',
drivingOptions : DrivingOptions,
unitSystem: google.maps.UnitSystem.METRIC,
durationInTraffic: true,
avoidHighways: false,
avoidTolls: false
}, response_data);function response_data(responseDis, status) {
if (status !== google.maps.DistanceMatrixStatus.OK || status != "OK"){
console.log('Error:', status);
// OR
alert(status);
}else{
alert(responseDis.rows[0].elements[0].distance.text);
}});
Please refer this document click here
This API can solve your problem - https://distancematrix.ai/dev
It takes into consideration the traffic conditions, road constructions, and other restrictions when calculating travel time. And if you were using Google's API before for you will be easy, because you don't need to rewrite code.
Regarding the departure time, you will find the following in the documentation:
"departure_time — a desired time of the 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). If neither time is specified, the departure_time defaults to now (that is, the departure time defaults to the current time). The departure_time must be set to the current time or some time in the future. It cannot be in the past. Results for a given request may vary over time due to the changes in the road network, updated average traffic conditions, and the distributed nature of the service. Results may also vary between nearly-equivalent routes at any time or frequency."
Follow these recommendations, and you won't have this problem. Besides, you can easily contact the developers and ask any questions concerning your situation.
Disclaimer: I work at a company that creates this API.
If you are using golang client, set DepartureTime to "now" in the input parameter DirectionsRequest of the Directions func.