I've tried to use access hours in FindSequence request^
destination1=FrankfurtAirport;50.050639,8.569641;acc:mo07:30:00+00:00|mo11:00:00Z;st:600
It's simial docs. And I've got an error:
"Cannot parse time: mo07:30:00 00:00. Hours must be in the range [0,23], minutes and seconds in the range [0,59]. Error ID: aa307f79-b9ae-489d-b0a9-52f8607b2ca1"
How can I fix it?
The waypoint id can be followed by a semicolon separated list of constraints. Supported constraints:
before, acc,at,st
The value consists of two timestamps with day, time and time zone information in the format:
acc:DDhh:mm:ss[Z|(+|-)hh:mm]|DDhh:mm:ss[Z|(+|-)hh:mm]
For access hours days (DD) are abbreviated with two lowercase characters: mo for Monday, tu for Tuesday, we, th, fr, sa, su. Hours (hh) must integer values in the range 0..23. Minutes and seconds must be from the range 0..59. The first time stamp defines the beginning of the access hours, the second time stamp defines the end of the access hours.
The format is as xsd type xs:datetime. The access hours constraints require a service time, which is the length time (to be spent) at the waypoint.
To specify a time zone, you can either enter a date in UTC time by adding a "Z" behind the date, or an offset from the UTC time by adding a positive or negative time behind the date
for example:
2019-09-24Z or 2019-09-24-06:00 or 2019-09-24+06:00 // acc:mo09:30:00-01:00|12:00:00-01:00;st:600
Supporting with illustration covering both formats :
https://wse.api.here.com/2/findsequence.json?departure=2019-05-04T8:00:00-01:00&mode=fastest;car;traffic:disabled&app_id=XXXXXXXX&app_code=YYYYYYYY&start=DuisburgRuhrort;51.4541,6.7406&destination1=ZecheZollverein;51.486,7.0459;acc:mo09:30:00-02:00|mo12:00:00-02:00;st:600&destination2=KokereiZollverein;51.4879,7.0337;acc:mo07:30:00Z|mo11:00:00Z;st:600&destination3=MuehlheimRuhrHbf;51.432,6.886;acc:mo07:30:00Z|mo11:00:00Z;st:600&end=DuisburgHafen;51.4576,6.7717&improveFor=TIME
For more details,refer : developer.here.com/documentation/routing-waypoints/topics/api-reference-findsequence.html
Related
I have a dataset file with a time variable in "seconds since 1981-01-01 00:00:00". What I need is to convert this time into calendar date (YYYY-MM-DD HH:mm:ss). I've seen a lot of different ways to do this for time since epoch (1970) (timestamp, calendar.timegm, etc) but I'm failing to do this with a different reference date.
One option is to simply add 347133600s (11 years) to each value in seconds. this will then allow you to simply use conversion as it would be from 1970-01-01.
So my task is too use SPSS to get just the hour from my datetime value, apply the UTC offset in order to get the user local time (just the hour value). So far I have managed to get just the hour from my datetime value, I recoded the value with my hour variable + the utc offset however now some of my values are
Datetimes are just formats. The actual values represent seconds from Oct 15, 1582. The mapping to the display format and the date creation, extrapolation, and date arithmetic functions use the underlying numeric value independent of the format. You could create a string value that reflected local time, but the standard display functions do not provide for a time zone.
I was asked to create a query to pull a near-real-time report from an Informix database (I have select access only, I cannot create a SP) and I felt like I succeeded pretty well until I realized that there was a discrepancy in a datetime field. it seems that the program that is populating the db is hard-coded to enter the time in the datetime field in UTC (five hours off of the local time. When the time was 2:30 it entered a row in the database saying John Doe completed the task at 7:30). In my report I am supposed to calculate the number of seconds (as an int) since the user completed the task (field is "completionTime") and I was originally just using:
sysdate - completionTime interval seconds(9) to seconds cast to char then cast to int
When I realized the mistake in the timezone of the completionTime field I just subtracted the offset as an integer (I was already converting the interval to an integer, so I just adjusted the answer by 18000). This worked just fine until Daylight Saving started. Then all of a sudden local time was 4 hours (14400 seconds instead of 18000) off of UTC.
Since I can only select from the db, I next tried using an inefficient case statement (my query went from <0.5 seconds to 3-5 seconds for only 25 rows). Following a suggestion from another forum I changed the time to an integer of seconds from the unix epoch, then used the dbinfo('utc_to_datetime') sp to convert it back to a datetime in the right timezone.
This approach works, but the calculation looks terrible to me:
cast(cast(cast((sysdate - dbinfo("utc_to_datetime", cast(cast(cast((completionTime - TO_DATE('Friday January 1, 2010 0:00', '%A %B %d, %Y %R')) as interval second(9) to second) as char(10)) as int) +1262304000)) as interval second(9) to second) as char(10)) as int)
notice that I am calculating the length of time from the completiontime to 1-1-2010 then adding 12 billion seconds (going all the way back to the unix epoch is too big for Informix's interval seconds(9) to second, hence the two-steps) so that I can then plug it into the dbinfo("utc_to_datetime") sp to convert it back to a datetime in the right timezone, then subtracting it from sysdate. The worst part (besides the six casts) is that the completiontimes that I am dealing with are all within 24 hours of sysdate, most are within 10 minutes, yet I am adding on 12 billion seconds so that I can use the only function I can find that converts between timezones.
My question is, Is this really the best way to do this? By the way, this works very quickly, and my query is back down to a reasonable execution time (<0.5 seconds), I'm just looking at this query and thinking that there has got to be a better way.
Jared
Maybe instead of sysdate you can use DBINFO('utc_current'):
SELECT DBINFO('utc_current') - (completionTime interval seconds(9) to seconds) FROM ...
moment("2013-12-31T19:51:57.000-0800").format("HH:mm") yields a 24hr hour format in GMT but I would like it in local time "11:51".
Is this possible with moment's format method?
That is incorrect. The code you gave will not show the the value in GMT. It will first adjust using the offset you gave it (-08:00), and then it will convert it to the correct offset as your own local time zone. So if you're time zone offset happens to be -08:00 for that particular time, you will see no conversion at all.
Also, you seem to be misunderstanding how the offset is applied. When you have an offset on an ISO8601 formatted string (like the one you supplied here), that means the time is already in the offset that is supplied. 19:51 is the local time that is in effect at the -8:00 offset.
To convert to UTC / GMT - you need to first invert the sign, then apply it. So the UTC time here is 3:51:57 AM on 2014-01-01.
Your requested output of 11:51 is not valid for this timestamp, no matter how you look at it.
I need to save a time interval in a column in a table. based on: http://docs.sqlalchemy.org/en/rel_0_8/core/types.html
I can use Interval type for that. My database is SQLite, and I don't quite understand this description in the document:
"The Interval type deals with datetime.timedelta objects. In PostgreSQL, the
native INTERVAL type is used; for others, the value is stored as a date which
is relative to the “epoch” (Jan. 1, 1970)."
Can anybody tell me how should I do that?
So from what I get in the question, you want to just store an interval and take it out of the database to use it again? But you want to understand how it is stored?
Concerning the storage: This is probably easier with Unix timestamps than with DateTimes. Suppose you want to store timedelta(1), i.e. a delta of one day. What is stored in the database is the time since the "epoch", i.e. second "0" in Unix timestamps and as a date: 1970-01-01 00:00:00 (this is where Unix timestamps start counting the seconds). If you don't know about epoch or timestamp, then read Wikipedia on Unix time.
So we want to store one day of difference? The documentation claims it stored "time since epoch". We just learned "epoch" is "second 0", so a day later would be 60 seconds per minute, 60 minutes per hour, 24 hours per day: 60 * 60 * 24 = 86400. So stored as an integer this is easy to understand: If you find the value 86400 in your database, then it means 1 day, 0 hours, 0 minutes, 0 seconds.
Reality is a bit different: It does not store an integer but a DateTime object. Speaking from this perspective, the epoch is 1970-01-01 00:00:00. So what is a delta of one day since the epoch? That is easy: it's 1970-01-02 00:00:00. You can see, it is a day later.
An hour later? 1970-01-01 01:00:00.
Two days, four hours, 30 seconds?: 1970-01-03 04:00:30.
And you could even do it yourself:
epoch = datetime.utcfromtimestamp(0)
delta = timedelta(1)
one_day = datetime.utcfromtimestamp(86400)
print "Date to be stored in database:", epoch + delta
print "Timedelta from date:", one_day - epoch
As you can see, the calculation is easy and this is all that is done behind the scenes. Take a look at this full example:
interval = IntervalItem(interval=delta)
session.add(interval)
i = session.query(IntervalItem).first()
print "Timedelta from database:", i.interval
You can see it is no different from the above example except it goes through the database. The only thing to keep in mind with this, is this note:
Note that the Interval type does not currently provide date arithmetic operations
on platforms which do not support interval types natively.
That means you should be careful how you use it, for example addition in the query might not be a good idea, but you should just play around with it.