A source's datetime settings decide how DataMind OS reads the datetime values it loads into the Lake. Use this page when loaded times are a few hours off, when 1C dates show the wrong year, or when a date shows as NULL.
Europe/ or an offset such as +4. The list is grouped by continent, with UTC first. Each row shows the city and country, the time there now, the offset in effect now and the zone name. A search with no match reads No time zone matches followed by what you typed.An empty Timezone means the same timezone as the platform. To go back to that, click Clear next to Timezone.
| Setting | What it does | Default |
|---|---|---|
| Timezone | The IANA timezone the source database writes its datetime values in. Leave it empty when the source runs in the same timezone as the platform. | Empty, the same as the platform |
| Datetime values | Keep as written (wall clock) stores each value exactly as the source shows it. The other option shifts each value from the source timezone into the platform's timezone on load. | Keep as written (wall clock) |
| 1C source (+2000 years) | Subtracts 2000 years from each value during extraction, and loads 1C empty dates (2001-01-01) as NULL. | Off |
Timezone accepts only a full IANA timezone name, for example Europe/. A fixed offset such as +05:00 is not accepted.
Only MSSQL and Azure SQL Database sources show the 1C source (+2000 years) toggle, on the Datetime step.
A few sources keep UTC by nature: Amazon Athena always runs in UTC, and BigQuery keeps TIMESTAMP columns in UTC and reads DATETIME columns as written. See Connect Amazon Athena and Connect BigQuery.
| Source | Step |
|---|---|
| SQL databases, Snowflake, BigQuery, Firestore, Firebase | Datetime |
| Files | General |
| Athena | Review |
| Connect any API | Streams and Review |
| RabbitMQ | Load & review |
Each form has its own page: Connect a database, Connect Snowflake, Connect RabbitMQ.
Datetime guide opens a dialog built from the timezone, mode and 1C setting selected right now. It rebuilds whenever you change one of them, and it never changes the source.
The dialog opens with: "How datetime values from this source land in the Lake with the currently selected timezone, mode and 1C settings. Press Start to walk through the example rows."
Start plays the example rows one at a time, showing the value in a small source table and where it lands in the Lake table. The rows cover:
UTC+04:00, a Berlin value of 10:00 lands as 12:00, and a New York value of 10:00 lands as 18:00.2299-12-31 23:59:59.The panels under the walkthrough list the settings under Fields and the rules that always apply under Fixed policies (always applied).
Whatever you choose, these fixed rules apply on load:
The offset applied to a value depends on its date. DataMind OS takes the offset of the source timezone for that date from the IANA timezone rules, so summer and winter times each get the right shift. On a daylight saving switch day with Keep as written (wall clock), the wall clock is kept as written, even across the skipped or repeated hour.
When you edit these settings of a saved source, the form warns you before you save:
Already-loaded rows keep the old datetime semantics - the new settings apply to future loads only (full-reload tables self-heal on the next run).
Changing these settings leaves rows that are already loaded as they are. Full Reload tables pick up the new settings on their next run; other tables keep their old values until their rows are loaded again. Check Choose a sync type before you correct history.
See Who can do what in the Lake.
First check Timezone. Set it to the zone the source writes its times in. If the source writes UTC, choose the UTC zone and the convert option. The Datetime guide shows this case as an example.
No. Full Reload tables pick up the new settings on their next run. Other tables keep the rows they loaded before the change.
Turn on 1C source (+2000 years) on the Datetime step. The toggle appears only for MSSQL and Azure SQL Database connections.
DataMind OS loads a value as NULL when it is before 1900-01-01, when it is an empty or zero date (such as MySQL 0000-00-00), when it is a 1C empty date, or when it cannot be read as a datetime.
Values above 2299-12-31 23:59:59 are clamped to that value. This applies to every source, whatever the settings.
No. A value that cannot be read as a datetime loads as NULL, and the load continues.
Keep the default, Keep as written (wall clock), when you want the Lake to show exactly the wall clock the source shows. Choose the convert option when you know the source timezone and want values shifted into the platform's timezone.
Each value uses the offset its timezone had on that date, taken from the IANA timezone rules. With Keep as written (wall clock), values on a switch day stay as the source wrote them, even across the skipped or repeated hour.
It is a suggestion from the source. After a connection test detects the source timezone, the section shows Detected: with the zone and the source clock, and Apply selects it; the line hides when that zone is already selected. On a Connect Any API source whose data sample holds datetime instants, the line instead reads "Detected instants in the sample - use {zone} + Convert" or "Detected instants in the sample - use {zone} + Keep as written", and Apply sets both the zone and the mode.
A full IANA timezone name, for example Europe/, chosen from the list. A fixed offset such as +05:00 is not accepted; Lake troubleshooting lists the message for a refused value.
No. The guide only previews the timezone, mode and 1C setting selected right now. It rebuilds when you change a setting, and closing it changes nothing.