You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Paul Taylor (Jira)" <ji...@apache.org> on 2022/06/02 02:37:00 UTC

[jira] [Commented] (ARROW-16543) [JS] Timestamp types are all the same

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

Paul Taylor commented on ARROW-16543:
-------------------------------------

[~terusus] how did you construct the Timestamp Vectors? The semantic meaning of the type is "<duration> since the epoch," so it's valid for the different duration dtypes to have the same underlying representation.

> [JS] Timestamp types are all the same
> -------------------------------------
>
>                 Key: ARROW-16543
>                 URL: https://issues.apache.org/jira/browse/ARROW-16543
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: JavaScript
>            Reporter: Teodor Kostov
>            Priority: Major
>
> Current timestamp types are all the same. They have the same representation. And also the same precision.
> For example, {{TimestampSecond}} and {{TimestampMillisecond}} return the values as {{1652118180000}}. Instead, I would expect the {{TimestampSecond}} to drop the 3 zeros when returning a value, e.g. {{1652118180}}. Also, the representation underneath is still an {{int32}} array. Even though for {{TimestampSecond}} every second value is {{0}}, the array still has double the amount of integers.
> I also got an error when trying to read a {{Date}} as {{TimestampNanosecond}} - {{TypeError: can't convert 1652118180000 to BigInt}}.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)