Date of ServiceDetails Object

[Alexander MacLeod]

Hi everyone, 

I am new to using NRE data so I apologise in advance if this has been answered before or there is a simple solution I have overlooked.

Looking at the documentation for the LDBWS, I cannot see an object name which provides the date at which a ServiceDetails item begins. I want the date for when the ServiceDetails object is due to start so that I can replace the current std object from "15:34" to something more like "15:34 25/09/16". Those familiar with the NSDate in iOS will know just converting a string containing "15:34" will create a random day, month, year, etc. and can cause a real headache when calculating the difference between two times.

I am sure this is possible, but I can't seem to find a solution reading the current documentation. Thanks in advance.

[Matt A]

LDBWS works in real-ish time, so the journey date is implicit to the request time, adjusted by the timeOffset (default 0) and timeWindow (default 120).

Assuming you make a request with those values as their defaults, then the services returned in any request for CRS xxx would be relevant to that CRS between 0 - 120 mins from the current time, and always in the future. Just use todays date + the location time at the CRS to get a full datetime, and if it looks like it's in the past compared to the current date + time, then you can detect over midnight and add a day to compensate.

You'll have to make it a bit cleverer dealing with journeys that pass through the same location more than once or negative time offsets, but that shouldn't be too hard.

[George Goldberg]

On 26 September 2016 at 13:01, Alexander MacLeod <alexander...@gmail.com> wrote:

The problem happens when I use the GetServiceDetails operation with a serviceID I had saved earlier. There I have no reference to the date it is requested. Would I need to save that date alongside the serviceID or is there any other way?

On LDBWS, the service IDs expire a couple of hours or so after the service finishes its journey (when the schedule is deactivated in Darwin, I believe), so generally the date can still be inferred based on today and whether midnight has been crossed or not.

If you want service IDs that continue to have meaning for longer than the running life of that exact service, you probably want either the Push Port or the LDBWS Staff Version (the latter providing date-times instead of just times in its equivalent of ServiceDetails objects).

You can read about how to do the cross-midnight time inference in a way that's consistent with Darwin on the wiki: http://nrodwiki.rockshore.net/index.php/Darwin:Schedule_Element#Ordering

What programming language are you working in? There are open source convenience libraries in some which might be able to help you with this.

--

George

[Peter Hicks]

All,

To add to this conversation - ‘overnight handling’ is really quite tricky, as is timezone handling.

The OpenLDBWS and the Push Port sacrifice putting the date and time in messages and instead just use a time. I have a number of Java classes to work out what the correct date and time should be, and if many other users of both services are doing the same, it suggests that the next major release of both services should contain timestamps, as opposed to just raw times - do something once and make life easier for everyone!

Whilst I can understand the need to reduce bandwidth and storage requirements, there’s probably a pleasant balance of slightly increased bandwidth (which becomes less of an issue as time goes on) versus making downstream users jump through some flaming hoops to derive a time correctly.


Peter

[Allan Blundell]

Sorry to add to this again but i agree, while i just use Push Port. For people new to this data, overnight handling is tricky and that's from my experience. I myself have a few c# functions to check, and process times that cross the midnight boundary. On a whole including the date with the time would be a great idea even with the extra bandwidth required, I myself would find it very useful. It will certainly help new/other users to not "corrupt" or incorrectly handle the data i'm sure.