Inconsistent format - Date column in API - is Seatable Cloud always running the same version?

Moin zusammen,

I have two accounts in SeaTable - one for myself and one that I created for my employer - both in cloud.

There’s one thing I don’t understand with the date column type:

  • in my personal instance the content is always received as ISO date and time without timezone via API. Changing display of time (Minutengenau) has an impact on the API response - formats like below:
    Screenshot 2023-08-21 at 12.42.29

  • in my employers instance the content is always received as ISO date with time and timezone from the API. Changing of the format has no impact on the API respone.
    Screenshot 2023-08-21 at 12.40.51

Is there a user-accessible setting for the timezone? I couldn’t find it.
Is SeaTable cloud always running the same version? Can I see it somewhere?

thanks for your help

You must be using different parameters in your API calls.

No, there is not.


Thanks for the insights @rdb , however I’m using the same API call, just swapping the tokens in my .env file and restarting my dev server. So I’m not really clear yet what is happening…

Just as a background: I used my account while I was developing. The base was created from an Excel spreadsheet. The base in my employers account was created from an Excel sheet of the same structure, maybe with slightly newer data.
The only difference I noticed when working with the other account was the date formats in the API responses, but the actual settings of the columns in SeaTable are identical.

The API calls are the same. I realize though, that the “Default View” has different column order and hidden columns. Would you think it can make a difference?

I exported now the base to a dtable file and imported into my employers account and there I get the exact same responses as in my account.

So there must be a setting which is not user accessible, or the internal data format is different depending on when the base was created / imported.

I am not aware that SeaTable supports a timezone currently.

But you can try to help me to understand what is happening here. You can either

  1. create invitation links for both bases and send them to or
  2. use the “get metadata” API call to get the metadata of both tables and compare the results:
    Get Metadata

Best regards

Hi @rdb , just as a feedback, not real conclusion: With the base in question I was unable to create date-type fields which don’t contain the timezone, even entirely new columns. I changed the date column, do iso without time format, converted to text and back to date, tried all kinds of things, but the API would always send an iso date with time and timezone. I gave up on it a re-created the base from a newer version of the Excel sheet and everything works as expected (no time when turned off). I think. Is it expected, that the API always returns ISO format for dates and not the configured format?
I can deal with it, ISO is the best, but just curious.

Some more recent findings:

In list-rows the api response is like

“Eingestellt am”: “2023-07-11”

honouring, that the column is configured not to use time, but not honouring the output format which is DD.MM.YYYY

via list-rows-with-sql the dates come as date with time and timezone, regardless of the configured output format

“Startdatum”: “2023-08-17T00:00:00+02:00”
“Eingestellt am”: “2023-07-18T00:00:00+02:00”

This is by design. The format “DD.MM.YYYY” is only a UI effect.

The list-rows API always return the stored text for a cell (in ISO format for date column).

The SQL API always return date in ISO format with time zone of the server, including date column, create time column, modify time column.

1 Like

Thanks for your reply @daniel.pan !
It makes sense that the format is only a UI effect, but wouldn’t it also make sense to return the same format in both APIs?

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.