GTFS Realtime Stop Time Updates Timestamp type

[lolpro11]

Introduce yourself

No response

Ask a question

The message StopTimeEvent has a time field that is int64. Is there any use for this? If not, can we transition into a uint64 spec for the time field? This would be more uniform across all other timestamp fields in the GTFS Realtime Spec.

Other timestamp fields in GTFS-RT, all as uint64

• message Modification.last_modified_time
• message FeedHeader.timestamp
• message TripUpdate.timestamp
• message VehiclePosition.timestamp
• message TimeRange.start, TimeRange.end

[IvanVolosyuk]

I'm pretty sure it will be a breaking change due to encoding differences of sint64 and int64 in protobuf wire format.

[lolpro11]

I'm pretty sure it will be a breaking change due to encoding differences of sint64 and int64 in protobuf wire format.

I understand, but I don't think there is anyone using this format using negative timestamps. That is the question I am asking: is there anyone using GTFS-RT with message StopTimeEvent having a negative timestamp? Also, what uses would int64 have vs uint64?

[skinkie]

I think it comes from the fact that a unix timestamp is an signed 64bit value, because it may describe the period before 1970. Now I would completely agree that it does not make sense that the designer of GTFS-RT would ever consider describing realtime data before 1970 a thing. That having said, I don't even think protobuf is remotely smart enough to do useful things with respect to limitations in the serialisation. Otherwise minimum and maximum values in other fields would have created more optimal serialisations.

[IvanVolosyuk]

I'm pretty sure it will be a breaking change due to encoding differences of sint64 and int64 in protobuf wire format.

I understand, but I don't think there is anyone using this format using negative timestamps. That is the question I am asking: is there anyone using GTFS-RT with message StopTimeEvent having a negative timestamp? Also, what uses would int64 have vs uint64?

Well, I guess I confused sint64 and int64 in protobuf. Both use varint encoding and changing from sint64 to uint64 will produce different results due to zigzag encoding, thus that would be a breaking change. Changing from int64 to uint64 should be mostly harmless on wire format. It might break compilation of programs using those changed definition though.