Two remarks:

1. we probably should use a different annotation, because @DateBridge is not supported on java.util.Calendar: there's another annotation, @CalendarBridge. So either we go on adding one annotation per type or we deprecate the old ones and add a generic annotation.
2. we might want to revisit how @DateBridge @CalendarBridge annotations are structured. In particular, the "encoding" parameter, when set to "numeric", implies lossy data storage: zone ID / offset information is not stored in a simple timestamp from epoch. This is the kind of things that, if we really want to keep them, should be at least documented or trigger exceptions when bootstrapping.