Add support casting timestamp of micro/nanosecond

[fengpengyuan]

Some tables would have date time formats (columns of VARCHAR type) with microsecond or nanosecond precision. When trying to cast these to TIMESTAMP type, Presto will throw a cast error. We should support casting these higher precision date time formats to timestamp for better usability of Presto. Since timestamp only supports millisecond precision, the behavior of the casting should be to truncate to millisecond precision.

Test plan - Unit tests

General Changes
* Add support for casting microseconds/nanoseconds to Timestamp type, though with precision loss to Milliseconds.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fengpengyuan / name: Fengpeng (30d92fa84f35e017e7d9cfb7a8fdb3baecb8dff2)

[prithvip]

1. Please start the commit message with "Add support for..." and limit the commit title to 50 characters
2. Squash both commits into one commit
3. Since this a user-visible feature, add a release note describing the change

[arunthirupathi]

The change looks good.

Would this result in a perf regression for existing use cases as it tries new formats ? I can think of error cases, will have more results to try before it fails, but want to confirm your thoughts.

Change the release note to
support casting microseconds/nanoseconds to Timestamp type, though with precision loss to Milliseconds.

[fengpengyuan]

The change looks good.

Would this result in a perf regression for existing use cases as it tries new formats ? I can think of error cases, will have more results to try before it fails, but want to confirm your thoughts.

Change the release note to support casting microseconds/nanoseconds to Timestamp type, though with precision loss to Milliseconds.

Thanks for review.
Valid point, but I do not think it will cause much(any) regression. When parse the input timestamp string, the DateTimeFormatter will check each of these parsers (patterns) sequentially, per the doc. If users do not input micro/nanoseconds format, I think there will be no impact(regression). Only when users try the new pattern(micro/nano), it will iterate more parses in the list, but only subtle overhead imo (as very limited no. of new patterns added). If you have concerns, we can move all the new parsers to the end of the list, but that will break the code patterns a little we try to maintain. Thoughts?

[arunthirupathi]

Today in Presto, all the timestamps are stripped to Milliseconds at the converter layer, so the precision loss is ok.

but after this change, some operators will have weird behavior.

"cast('2001-1-22 03:04:05.321123' as timestamp)" = "cast('2001-1-22 03:04:05.321999' as timestamp)"

Since this is already happening other places at the connector, this precision loss is ok.

[arunthirupathi]

Let us wait for @prithvip to approve as well, then we can merge this. Give it a couple of days.

[prithvip]

@fengpengyuan Thank you very much for contributing this change. The code looks good to me, but could you please edit your initial comment to follow our release notes guidelines? https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines

[prithvip]

@fengpengyuan Thank you for updating the release notes. @arunthirupathi Let's go ahead and merge this.