Datetime not correct

Hi,

I have a very weir problem.

From a debian 12 server, i push from a python script a datetime :
import datetime
now = datetime.datetime.now()
timestamp = now.strftime(“%Y-%m-%d %H:%M:%S”)

I push timestamp into my Baserow api hosted on a container inside an ubuntu server.

If its 17:30 when i trigger the script, my debian server (pusher) sur 17:30. My ubuntu server is 17:30. My docker is 17:30, my baserow api dispaly 18:30.

How can i fix it ?

Hi,

Is it possible that it has something to do with a daylight saving time setting since the time difference is always one hour?

maybe, but i dont unedrstant why if my time zone is correctly set up in all the systems hosting my services.

Is there any setting inside baserow seting it up?

@davide could you please check this out?

Hello @Matteo,

Please note that the Baserow API uses UTC as the timezone for timestamps. This means that if you want to see the correct time in the UI, you need to convert your timestamp accordingly.

If you provide a timestamp in a different timezone, such as Europe/Rome, Baserow will consider it as a UTC timestamp. The UI will then convert it to the Europe/Rome timezone based on your browser timezone. During certain periods of the year, this will result in an hour being added to your timestamp. During daylight saving time, two hours will be added.

To avoid these issues, it is recommended that you use datetime.utcnow() instead of now to generate a timezone-aware timestamp.

1 Like

Thanks you for the information.

@olgatrykush This is actually quite a bit more problematic for no-code people and generally office users, as the same thing happens on CSV/XML/etc data export.

We have just realised that Baserow defaults to UTC, but it does not communicate this explicitly, and it is only apparent in data export - if one’s data is in a format which includes hours too, this leads to serious data issues.

Case A
Since Excel does not encode timezone, when one pastes data into a data field/column without a timezone (from any software, not only Excel), the data gets pasted and the correction happens without user awareness - so, the user pastes “23/09/2024 00:00” without time zone info on a device set to UTC+2 and the user sees “23/09/2024 00:00” in the field - but - upon export - this gets shifted to UTC value “22/09/2024 22:00”
(unless the device timezone happens to be UTC, of course)

Case B
Data is imported via Json
All fields are set to text.
User then changes one of the fields to Date without a timezone set.
If the device is set to anything other than UTC, this results in essentially data corruption on export.

Case C
that would be Airtable import - Fields imported from Airtable with time specified (but not timezone specified) get shifted like in case B → data loss/corruption.

Airtable does not interefere with pasted data - the export contains exactly what you see on the screen - some members of my team assumed Baserow behaves in a similar way, and I suspect many people do too.

This seems a bit like a bug, or at least a huge data format omission regarding feature awareness and visibility.
Is there a global default setting for this in Baserow?
I’d actually rather have Baserow NOT change the data at all - or have a global toggle for this.
So that there would be an option for date fields to behave the same way as in Airtable.

(or make it default to export what the user sees?)

Airtable:

imported to Baserow:

Baserow CSV (data imported from Airtable):
image

Airtable time zone seems to be interpreted differently, as shown in the screeenshots

Airtable CSV export:
image

interestingly - another database with manual inputs inside Baserow.
Note the change in behaviour for the column with Timezone set.

CSV Export:

I guess - this is because there is a difference between show and set timezone - for Airtable, the date field with timezone only shows it but not sets it - which frankly - is a bit confusing the way it is laid out in the field settings.

It is not at all clear what should one set to get the desired behaviour on export.

This is problematic, as now every time someone imports data from Airtable, they need to change every single date column to ensure the desired data export.

@davide could you please check this out?

Hey @dev-rd,

Yes, there’s currently a difference in how date fields without a timezone and those with a set timezone for all collaborators are exported.

Unfortunately, for technical reasons, at the moment we can’t yet export data in the same timezone as it appears in the browser if no timezone is specified.

However, we’re planning to introduce a timezone option in user settings, which would be used to localize all date fields that don’t have a specific timezone set and use that as the default for exports.

Do you think this would help your team resolve the issue?

a general setting for “default” timezone (if no timezone is set) would be great!

I guess that lack of user awareness that the date will be different on export (and for which settings) is the main thing to address here.
Maybe it would be possible do add some info about that directly in the time/date column settings?
Not sure about the UI here, but in this case I’d choose awareness over good looks or clean design every time :slight_smile: