Does that record:
a) Update the displayed time, changing with daylight savings, now out by an hour either way either 10:00 or 12:00 depending on the transition, or
b) Retain the same time and accounts for the hour difference
If you set a date-time field to a value of 11:00 on a particular date, then this means 11 o’clock local time on that date. It won’t matter whether this date is within daylight savings period or not; the value will not change, and should never become an hour out.
If you need to use this field in formulas/automations/reports, you might not get what you expect (see here) but the date on the UI will not change (assuming you don’t change your locale).
Note: there would be an issue if there is a change in policy for your locale, e.g. your country decides to stop using daylight savings
Are you sure? From what it says on the guide, the data for the time is stored in UTC, not in “Europe/Amsterdam” or whatever timezone. So when you change from GMT+1 to GMT+2 in daylight savings, the UI will show different time then, no?
So if i schedula a meeting for 9, then daylight saving time kicks in, it will show as 10 the next day? (or the other way around, idk, dst is horrible)
Imagine you are in western Europe, and you type 1 Jan 2025 11:00 on the UI. This will be stored as 1 Jan 2025 10:00 UTC on the backend, because there is 1 hr difference between UTC and western Europe on the 1st January.
If you type 1 July 2025 11:00 on the UI, it will be stored as 1 July 2025 09:00 UTC, because there is a 2 hr difference at that time of year.
No.
It doesn’t matter what happens over the course of the year (as Europe enters/leaves daylight savings) the statements above remain true.
Unless the user changes timezone (or Europe abolishes daylight saving) nothing will change this.
This is see, yes.
But if its March 29th, and i set something for march 31st to be at 10:00, then the times change, it will now show on the ui at 11:00, no? Its stored as 9:00 in utc, then my clock moves and now it shows an hour later. Isnt entering or leaving dst effectively just moving timezone? From UTC+1 it becomes UTC+2 or vice versa.
Im confused.
If you set something to be 31 Mar 2025 10:00 (on the UI) then it will always show as 31 Mar 2025 10:00 on the UI 
(unless you change your timezone)
It doesn’t matter when you do it, today, tomorrow, next year …
(It will be stored as 31 Mar 2025 09:00 UTC internally, but you shouldn’t actually need to care about that. When storing, Fibery doesn’t decide how many hours to subtract based on the current time difference, but based on the time difference that will apply on 31 Mar 2025)
A thought experiment to explain this. Our team is quite international, and people travel a lot, so I find myself thinking about timezones (and DST) a lot.
I’m in UTC+3. If I set a time for noon, that date value will actually be stored as 9am (since it’s UTC), and in my UI Fibery makes the calculation to noon based off my OS’s locality settings. My colleague living in UTC+2 would see this same date value as 11am, correct?
Now for part two of this thought experiment. Say a due date was set for March 9 at noon in the US, Eastern time zone (this was the first day of DST, UTC-4), so it is stored as 16:00 UTC). For people in Eastern, the date will always appear as March 9th 12:00pm. However, noon of March 8th is actually 23 hours before the due date (since non-DST time is UTC-5). This hour-off discrepancy continues until DST begins at March 9th at 2am, which becomes 3am, which is 9 hours before the due date. So because the due date is in DST, it was stored with daylights savings, i.e. UTC-4, even though we were still in non-DST time (UTC-5).
@ChrisG, let me know if this is correct or not.
Correct.
Sounds right.
Correct. The time difference between midday on one day and a subsequent day is not always 24hours 
| Local date time 1 | Local date time 2 | Difference (in hours) |
|---|---|---|
| March 8th 01:59 | March 9th 01:59 | 24 |
| March 8th 02:00 | March 9th 02:00 | Not possible - there is no March 9th 02:xx |
| March 8th 03:00 | March 9th 03:00 | 23 |
| March 8th 12:00 | March 9th 12:00 | 23 |
| March 8th 23:59 | March 9th 23:59 | 23 |
| March 9th 00:00 | March 10th 00:00 | 23 |
| March 9th 01:59 | March 10th 01:59 | 23 |
| March 9th 02:00 | March 10th 02:00 | Not possible - there is no March 9th 02:xx |
| March 9th 03:00 | March 10th 03:00 | 24 |
You can check here.
100% correct 
(except I might write it as “So because the due date-time is in DST …” since the switch to DST happens part way through the date in question)
Ultimately,
yes, and it makes the calculation determined by the timezone for your current locality as it will apply at the date-time being chosen.