How should I deal with UTC time decoded AIS data ?

[DanAlz]

I've used this library to decode AIS data but I don't know how I should work with time. some records have UTC time and some data have just timestamp. these time aren't understandable to me. for example, I don't know ('utc_hour': 17, 'utc_min': 10, 'utc_spare': 0 ) what exactly means. I'll annex a file that you could see. 1.txt

[schwehr]

{'id': 1, 'repeat_indicator': 0, 'mmsi': 538004431, 'nav_status': 0, 'rot_over_range': False, 
 'rot': 0.0, 'sog': 11.699999809265137, 'position_accuracy': 1,
 'x': 57.63802833333333, 'y': 25.3185, 'cog': 120.5, 'true_heading': 120, 'timestamp': 17,
 'special_manoeuvre': 0, 'spare': 0, 'raim': False, 'sync_state': 0,
 'slot_timeout': 4, 'slot_number': 670}

AIS is a terrible system when it comes for time. Life is better when the metadata wrapping the logged NMEA message contains a complete timestamp. Then you only have to contend with the time delta between when an transmitter created a message, when it was received, and the clock offset of the receiver (e.g. the USCG NAIS was sometimes off by up to 48 hours in its receivers)

For AIS messages 1, 2, and 3: If you only have this decoded in-message content, then you get different time info depending on what slot state is. Sometimes the message will have the hour and minute, sometimes not. It always has second of the minute.

Message 4 always has the year, month.

So if you don't have good metadata, you'll need to write a fancy filter to keep track of time and assign a datetime to each message based on those around it.

[bjornasm]

A bit late, sorry @schwehr , but could you expand on:

when you only have to contend with the time delta between when an transmitter created a message, when it was received, and the clock offset of the receiver

How to you do that? Is there a automatic report from the receivers where you can infer a clock offset?

[schwehr]

If you are getting the data from somewhere else, you might not be able to resolve things for all messages. For example, if the receiver isn't logging time or the receiver's sense of time is incorrect and your logger doesn't also timestamp the messages received from the AIS network, you may well be out of luck. If you really want the best sense of time for each received message from an entire AIS network, you could construct a system that looks at the whole series of NMEA messages with all the timestamps from logger, to receiver, to inside all the various messages, you could construct a system that could assign a best fit time and likely time error for each message.

Ever one of those timestamps might have an incorrect clock and some unknown delay between the timestamp to when the message is logged. It's usually small, but some systems can have large and/or variable delays.