---
title: "Importing Dates"
canonical: "https://servicedesk.maxgeo.com/space/DS/1436450836/Importing%20Dates"
format: markdown
---
**Importing Dates**
Dates and times can be tricky to import because there are a few different formats used in the DataShed back-end like:
**Date** – contains no time component
Example: Date_Started/Date_Completed in the DH Collar table
**Time** – contains no date component
Example: Time_Loaded/Time_Dumped in Prod Material Movement table
**Datetime** – contains a date and a time component
Example: Logged_Date, Sampled_Date, Survey_Date
**Datetimeoffset** – contains a date, a time and a time zone component
Example: Load_Date and Modified_Date
**General**
- While you can have columns in the same file which are date and other datetime, you can’t have a mix of different date **formats** in the same file, and definitely not in the same column. If you use dd/mm/yyyy for date columns (and by implication dd/mm/yyyy hh:mm:ss for datetime columns) then all date columns and all date values need to follow that format.
- The destination field type in the DataShed back-end table to which you’re importing will dictate whether a date and time is supported or only a date.
- Excel automatically reformats dates and saves Excel date codes which may lead to unexpected results when importing. The best way to see what is really there, is to format your date columns as Text inside of Excel itself so that no hidden conversions can apply.
- Never open a CSV file with Excel and then save the file even as a CSV file again, the date conversions will already be applied and ruin your CSV file.
**Importing from CSV files**
When you’re importing from a CSV file, things are a bit more straightforward because when you open the file in Notepad (NOT Excel!), what you see is what you get, and the simple rule is to ensure that the dates follow the correct formats for each date type and in the Import Layout, specify which of the 2 masks are applicable.
Date: dd/mm/yyyy or mm/dd/yyyy
Datetime: dd/mm/yyyy hh:mm:ss (14/01/2020 07:30:00) or mm/dd/yyyy hh:mm:ss (01/14/2020 07:30:00)
Using something like 14/01/2020 07:30 where the seconds are missing will result in the importer not being able to interpret the date and neither of the import masks will work. You have to be exact.
Datetimeoffset is not supported for import and only used on the audit fields.
**Importing from Excel files**
Whether you choose to stick to the Excel formatted dates or format those columns as text and work with the real date values, the important part is to check these columns to see if all dates are consistent.
The alignment within the column can sometimes give you a clue if there is an error because most dates will be right-aligned but erroneous ones which can’t be interpreted properly because dd and mm are switched, will be left aligned.
Apply a specific date format to such columns in Excel to check if all can be converted.
Be wary of dates that could be interpreted either way such as 10/1/2024 which could be interpreted as 10 Jan 2024 or as 1 Oct 2024. Excel will interpret it successfully but it could be wrong anyway.
Look at dates that can’t be ambiguous like 14/1/2024. This can only be 14 Jan 2024 as there is no month 14.