search

tbsalling / aismessages

AISmessages is a Java-based light-weight, zero-dependency, and ultra-efficient message decoder for maritime navigation and safety messages compliant with ITU 1371 (NMEA armoured AIS messages). A live demo of AISmessages is available on http://ais.tbsalling.dk.
https://github.com/tbsalling/aismessages/wiki
Other
156 stars 66 forks source link

Add methods to retrieve ETA month/day/hour/minute #23

Closed dhoepelman closed 6 years ago

dhoepelman commented 6 years ago

Currently the ETA is only available as a string. This causes us to have to parse that string to get the numeric values, which feels unnecessary as the AIS message directly contains the numeric values.

I have not cached the string in this implementation (instead caching the integers), if desirable I can add that

tbsalling commented 6 years ago

As an alternative solution, one might consider to return ETA as a java.time.ZonedDateTime. But we're fine to go with int as well.

I don't think caching the String will be required. Instead I think we should deprecate the old getEta() method.

dhoepelman commented 6 years ago

Fair enough, I'll update the PR.

The problem with returning a Instant or ZonedDateTime is that the AIS message does not include the year, so you need the metadata received to reliably return that.

Then you get into the problem of bad user input, we have seen ships with an outdated ETA. E.g. 2018-07-01 12:00 the ETA was 07-01 06:00, this is most likely 2018-07-01 06:00 But what if the ETA is 04-01 06:00 at 2018-07-01 12:00, should that be interpreted as 2018-04-01 06:00 or 2019-04-01 06:00?

I'll add a simple proposed solution which should be reasonable for normal use-cases, but the "raw" values should be available if a user wants custom business rules for this case

edit: I see you merged already, ill still open a PR with your later comments

tbsalling commented 6 years ago

I absolutely agree with your analysis, and I have also seen a lot of dirty/obsolete/weird data values in real-life messages.