Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local_Time Conversion error #734

Open
kiimot opened this issue Jan 23, 2023 · 3 comments
Open

Local_Time Conversion error #734

kiimot opened this issue Jan 23, 2023 · 3 comments
Labels
🐛 bug unexpected or wrong behavior ⏳ waiting dependency internal dependency development required

Comments

@kiimot
Copy link

kiimot commented Jan 23, 2023

Hi! I'm doing some tests, and when I try to convert a String format variable to LocalTime, when you insert it into the table it looks correct, but if you view it from the dashboard it doesn't.

However, when the variable is read from a CSV file, it is displayed correctly in both the table and the dashboard.

Is it possible that I am doing the process of passing from String to LocalTime wrong? It inserts it correctly into the table, but it doesn't work correctly

Steps to reproduce

If from Atoti, I read a CSV that contains a LocalTime field and when reading the CSV I indicate that this field is LocalTime, it works correctly
image

If I do a logs.head() it works correctly and in the dashboard too...
image
image
image

But if I try to pass to an endpoint, a String to LocalTime transforms it correctly and inserts it correctly in the Logs table:
image
image

But if I check the dashboard, it doesn't show the same as the table.
image

Actual Result

image

Expected Result

image

Environment

  • atoti: 0.7.2
  • Python: 3.10.9
  • Operating System: Windows 10 Enterprise

Logs (if relevant)

@kiimot kiimot added the 🐛 bug unexpected or wrong behavior label Jan 23, 2023
@tibdex
Copy link
Member

tibdex commented Jan 23, 2023

Hi,

In your append_rows_to_table() endpoint, can you try printing the whole rows to show that not only the first row is good but all the other ones too?

Instead of Table.append() can you try to use Table.load_pandas() passing it a DataFrame where you made sure that the HMS_INI and HMS_FIN columns both have the good type (time and not string or something else)?

@kiimot
Copy link
Author

kiimot commented Jan 24, 2023

Hi,

Of course, I put a screenshot of before and after the conversion
image

And reference to the issue of changing the append to load_pandas, it still doesn't work
image

The result remains the same for both changes
image

Thanks for your time

@tibdex tibdex assigned tibdex and unassigned kiimot Jan 24, 2023
@tibdex
Copy link
Member

tibdex commented Jan 24, 2023

Hi,

I can reproduce the error with this simpler code:

from datetime import datetime, date, time

import atoti as tt

session = tt.Session()

table = session.create_table("test", keys=["id"], types={
    "id": tt.INT,
    "datetime": tt.LOCAL_DATE_TIME,
    "date": tt.LOCAL_DATE,
    "time": tt.LOCAL_TIME
})
cube = session.create_cube(table)
l, m = cube.levels, cube.measures

table += (1, datetime(2023, 1, 24, 16, 57, 0), date(2023, 1, 24), time(16, 57, 0))

table.head()
#               datetime       date            time
# id                                               
# 1  2023-01-24 16:57:00 2023-01-24 0 days 16:57:00

When I look at the Arrow table created to transfer the row from Python to the atoti server, I get this:

pyarrow.Table
id: int32
datetime: timestamp[ns]
date: date32[day]
time: time64[ns]
----
id: [[1]]
datetime: [[2023-01-24 16:57:00.000000000]]
date: [[2023-01-24]]
time: [[16:57:00.000000000]]

so the types are right but something goes wrong after since I also get wrong data from the server in the pivot table:

Screenshot 2023-01-24 at 17 02 26

The issue also occurs with a query launched from Python:

cube.query(m["contributors.COUNT"], levels=[l["datetime"], l["time"]])
#                                contributors.COUNT
# datetime         time                             
# 2023-01-24T16:57 61020000000000                  1

This is tracked in an internal ticket, I'll let you know when this is fixed.

@tibdex tibdex removed their assignment Jan 24, 2023
@tibdex tibdex added the ⏳ waiting dependency internal dependency development required label Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug unexpected or wrong behavior ⏳ waiting dependency internal dependency development required
Projects
None yet
Development

No branches or pull requests

2 participants