[ 
https://issues.apache.org/jira/browse/QUICKSTEP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469255#comment-15469255
 ] 

ASF GitHub Bot commented on QUICKSTEP-53:
-----------------------------------------

Github user hbdeshmukh commented on a diff in the pull request:

    https://github.com/apache/incubator-quickstep/pull/98#discussion_r77750246
  
    --- Diff: types/DatetimeLit.hpp ---
    @@ -51,53 +54,70 @@ struct DateLit {
             + 1   // -
             + 2;  // Day
     
    +  // Years should be between [-kMaxYear, +kMaxYear] inclusive both end.
    +  static constexpr std::int32_t kMaxYear = 99999;
    +  static constexpr std::uint8_t kBitsNeededForDay = 5u;
    +  static constexpr std::uint8_t kBitsNeededForMonth = 4u;
    +
       static DateLit Create(const std::int32_t _year,
                             const std::uint8_t _month,
                             const std::uint8_t _day) {
         DateLit date;
    -    date.year = _year;
    -    date.month = _month;
    -    date.day = _day;
    +    // Normalize year by adding kMaxYear value, because we try to
    +    // encode signed year value into an unsigned integer.
    --- End diff --
    
    The check for leap year plays a role In the implementations for operator + 
and - for the date type. For instance, to perform an operation like 
``-2000-29-01 + 13 months``, we need to know if the resultant year will be leap 
or not. It seems that this check for leap year will be performed on the 
normalized year instead of the original year. 


> New representation and faster comparison operators for DateLit
> --------------------------------------------------------------
>
>                 Key: QUICKSTEP-53
>                 URL: https://issues.apache.org/jira/browse/QUICKSTEP-53
>             Project: Apache Quickstep
>          Issue Type: Improvement
>          Components: Types
>            Reporter: Hakan Memisoglu
>            Assignee: Hakan Memisoglu
>
> DateLit structure contains 3 member: 
> 32i for year,
> 8u for month,
> 8u for day.
> Instead we can put all year, month, and day information into 32u. It will 
> benefit from having a smaller sized representation.
> The new representation also provide faster comparison operator by directly 
> using 32u comparison operators that have corresponding assembly primitives 
> (instead of using if else branches).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to