Add support full usage of Time/Timestamp/DateTime struct types beyond literals

[yogendra-17]

Summary

Currently, Time, Timestamp, and DateTime types are only partially supported in the LLVM lowering pipeline.

While literal construction works correctly, these types cannot be used in actual programs beyond being embedded as constants.

Additional Information

Code of Conduct

• I agree to follow the Code of Conduct

[yogendra-17]

@yuvimittal , can i get assigned?

[hemannt003]

Hi @yuvimittal , I’d like to work on this.

From what I understand, the current limitation is that Time/Timestamp/DateTime types are only supported as literals in the LLVM lowering pipeline, but not as fully usable values in computations.

My plan is to:

• Extend the type representation in the IR/lowering stage so these types can be handled beyond constants
• Implement proper lowering for operations involving these types (e.g., passing through functions, assignments, and basic transformations)
• Ensure consistency with existing literal handling while keeping the changes minimal and backward-compatible

I’ll start with a small, incremental approach (supporting basic value propagation and function usage) before extending to more complex operations.

Please let me know if this direction aligns with your expectations!

[yogendra-17]

@hemannt003 , i opened the issue with the intention of working on it, hope you find different issue to work on!

[yogendra-17]

@xmnlab @yuvimittal , I've been working on adding temporal type support (Time, DateTime, Timestamp) to the LLVM-IR builder in irx. The IR-level groundwork is already in place , TIME_TYPE, TIMESTAMP_TYPE, and DATETIME_TYPE are defined as LLVM literal struct types, and I've written all the helper methods for struct field access, runtime struct construction, field-wise comparison (==, !=, <, <=, >, >=), and zero-initialization for variable declarations.
However, I've hit a blocker on the astx side. The current astx version has LiteralTime, LiteralDateTime, LiteralTimestamp (which work fine for compile-time constants), and Time/DateTime/Timestamp as type descriptors, but it's missing the following AST nodes that are needed to make temporal types fully usable at runtime:

What's missing in astx:

• TimeExpr, DateTimeExpr, TimestampExpr, expression nodes for constructing temporal values from runtime sub-expressions (e.g. variables or function call results, not just literal strings). Without these, you can write "12:30:00" as a literal but not Time(hour=h, minute=m, second=s) where h, m, s are runtime values.

• StructFieldAccess, a node for reading a named field from a struct value, e.g. my_time.hour. Without this, there's no way to extract individual components from a temporal value after construction.

What this would unlock:
With these nodes added to astx, the irx LLVM-IR backend would be able to support:

• Declaring variables of type Time, DateTime, Timestamp
• Constructing them from runtime integer expressions
• Reading individual fields (my_time.hour, my_ts.year, etc.)
• Comparing two temporal values with ==, !=, <, <=, >, >= using lexicographic field-wise comparison
• Passing temporal values as function arguments and return values
• Full integration with the existing BinaryOp, VariableDeclaration, and FunctionPrototype visitors

This would make irx one of the few LLVM-based compilers with first-class native temporal type support, which is a meaningful differentiator for data-engineering and analytics use cases.

My question:
Should I add these nodes directly to the astx repo (and if so, is there a preferred pattern I should follow, I see StructDefStmt uses ASTNodes for attributes which seems like the right model), or would it be better to define them as local stubs in irx and propose upstreaming later?
I have the irx-side implementation ready to go either way, I just need the AST node definitions to hook the visitor dispatch into.
Happy to open a draft PR on astx if that's the preferred path.

[yogendra-17]

[xmnlab]

Hi @yogendra-17 , thanks for raising that up.
Not sure if I am following you.

But if i understood correctly, maybe there is no need to create new classes.

So it could still be used as, for example, DateTime(f"{h}:{m}:{s}")

But if you want to improve that to use keywords, probably we could improve the __init__ of their classes to have something like (for example)

def __init__(self, value, /, h,m,s): ...

Sorry if I didn't understand the issue you raised