Rework 1.1 Timestamps

[almann]

This is currently fairly confusing, we should rework this section.

I like this, though it is interesting that the least significant bits in our representation correspond to the most significant field. So are timestamps have effective big-endian with respect to its fields. I think this effectively makes timestamps mixed-endian.

_Originally posted by @almann in https://github.com/amazon-ion/ion-docs/pull/215#discussion_r1195614957_

[almann]

Current thinking of how we might revise this:

[liigo]

Hi all, i think the short-form timestamps occupied too many opcodes (0x80-0x8C), and some of which are not very useful in most commonly use cases (e.g. 80, 81, 83, 86, 87, 88, 8b, 8c). (sorry if I'm wrong.)

Edit: maybe we could optimize (by using short-form encoding) for most commonly use cases only, where Year+Month+Day always stand together, and Hour+Minute+Second always stand together too. And leave others to Long-form timestamps.

[popematt]

Based on our experience, interactions with Ion users, and data about current use cases, we designed the short-form timestamps to cover the most common precisions and the UTC offsets for all known timezones. We expect that usage of the long-form timestamp encoding will be rare, and thus will not benefit form additional op codes.

@liigo, do you have a specific case of long-form timestamps that you believe would benefit from having a separate op code?

[liigo]

@popematt No. I thoutht long-form timestamps encoding (op F8) can contains everything of any timestamp. (maybe I'm wrong)