-
Notifications
You must be signed in to change notification settings - Fork 8
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
Issue parsing dates #53
Comments
To write value to SeaTable rows, you can refer https://seatable.github.io/seatable-scripts/data-structure/ . For date, it should be 2020-01-01 or 2020-01-01 10:00 . Without timezone information. In the server side, it will use local timezone of the server to handle date and time. |
Ah! So the |
For SQL Query result Date column: The string stored in date column have no timezone information, if time part contained in the string, it is treated as the time at the server's timezone, and converted to UTC time and returned. If no time part contained in the string, it always returned as 00:00:00Z. Create time column and modified time column: The string stored contains time zone information, the correct ISO format time will be returned. |
This warning is removed in v2.5.2. |
@freeplant thanks for earlier comments. I have also run into this recently. For the same self-hosyed server running in UK timezone (and therefore UTC in winter and UTC+1 in summer) I see a mix of formatting based on whether the datetimes are in summer or winter when doing SQL queries. My hypothesis is that they look like something like this:
when passed to
|
* see seatable/seatable-api-python#53 * and test
Hi! Reading
date
columns throws multiple warnings.Consider the following table with a couple empty (
None
) rows:Fetching the
my_date
column throws two types of warnings:The culprit for this appears to be this line:
seatable-api-python/seatable_api/utils.py
Line 139 in 9922141
Apparently,
datetime.fromisoformat
does not like the trailingZ
(see this post on stack overflow):The problem here is that the same try/except block as above does not cater for empty rows.
These issues are obviously not show stoppers but since each row will cause a warning (that can't be suppressed because it's a
print
statement) this becomes really annoying for longer tables.On a general note: Is that implicit (re-)formatting strictly necessary? For example, I'm typically converting data into
pandas
data frames anyway andpandas.to_datetime()
has no issues with the full string - even parses the correct time zone:FYI: This is with
seatable_api
version2.5.1
.I also have a separate question on writing dates to SeaTable: I've tried writing a timestamp back to the table (via batch update) and it appears as if for iso-formatted strings (e.g.
2021-12-01T11:00:05Z
) the date is correct ingested but the time is dropped. Can you tell me what the expected format is?Thanks,
Philipp
The text was updated successfully, but these errors were encountered: