[FEA] Support timestamp nanoseconds in CastStrings toTimestamp

[rishic3]

Is your feature request related to a problem? Please describe.
We have a UDF that takes timestamp strings -> parses and converts between timezones -> stores as strings, preserving nanosecond precision. While this can be done manually using cuDF, it would be great to leverage CastStrings.toTimestamp in the JNI out of the box. However, toTimestamp currently only supports microsecond precision.

Describe the solution you'd like
Add nanosecond support to CastStrings.toTimestamp and dependent methods.

Describe alternatives you've considered
Parsing manually using cuDF is doable, but verbose and not as maintainable.

[abellina]

I discussed this issue with @rishic3, and it's a nice to have for now. At the moment, there is a mix of cuDF and spark-rapids-jni APIs one uses for UDFs, which is a bit confusing, but it works.

[mythrocks]

At the moment, there is a mix of cuDF and spark-rapids-jni APIs one uses for UDFs, which is a bit confusing, but it works.

Does this mean there is already a solution for nanosecond timestamp strings? Is it slower, or is it complicated?

[abellina]

At the moment, there is a mix of cuDF and spark-rapids-jni APIs one uses for UDFs, which is a bit confusing, but it works.

Does this mean there is already a solution for nanosecond timestamp strings? Is it slower, or is it complicated?

We have a UDF that takes timestamp strings

@rishic3: Do we have a link to the source code for the nanosecond timestamp UDF?

Yes using the casting code in cuDF. For now, we need to document where the user should go for each operation. In this case, it's mostly the cuDF casting code.

[mythrocks]

Circling back to this: For now, the workaround should suffice. We can revisit once the priority increases for the user.

cc @sameerz.

[rishic3]

To add more context, in addition to dashed ISO formats, we require these compact/slash formats

// yyyyMMdd'T'HHmmss[SSSSSSSSS]
"%Y%m%dT%H%M%S%9f"

// yyyyMMdd HHmmss[.SSSSSSSSS]
"%Y%m%d %H%M%S.%9f"
"%Y%m%d %H%M%S"
    
// MM/dd/yyyy HH:mm:ss[.SSSSSSSSS]
"%m/%d/%Y %H:%M:%S.%9f"
"%m/%d/%Y %H:%M:%S"
    
// yyyyMMdd'T'HHmmss.SSSS
"%Y%m%dT%H%M%S.%9f"
"%Y%m%dT%H%M%S"

which (afaict) is anyway not supported by CastStrings, so we'd need to go down to cuDF even with nanos support.
Supporting the formats above could be a separate issue, but the workaround suffices.