Input data is specific to the component models that you use, but typically consists of climate, topography, land use, rainfall, and management practices. Examples of these are provided in Tables 1 and 2.
...
The TIME framework (used by Source) uses a subset of the ISO-8601 standard. The central part of this subset is the use of the format string:
yyyy-MM-ddTHH:mm:ss
| Info | ||
|---|---|---|
| ||
| Note: Microsoft Excel does not detect dates with the T symbol between the date and time. ISO-8601 permits replacing it with a space for the purposes of interchanging data and Excel will recognise that representation regardless of your regional and language settings. |
Dates should comply with the ISO 8601 standard where possible but more compact formats will be read if unambiguous. For example:
- the dates 24/01/2000 (Australian) and 01/24/2000 (USA) are unambiguous; but
- the date 2/01/2000 is ambiguous and depends on the local culture settings of the host machine.
...
Possible problems with time-steps
Incorrectly-formatted date and/or time entries will result in errors if Source is unable to interpret your data file (eg. LoadDataFileIOException). You may also need to check your data if you use an ambiguous date format.
There are two known problems where a time step may be incorrectly detected:
- When reading a file on a computer with US settings, because of the mm/dd/yyyy date format. This may happen if the whole of a daily time series covers less than 13 days, or less than 12 months for a monthly time series; or
- When reading a file which has years in two digit format (eg. 30/01/99) instead of four digit format (eg. 30/01/1999). An error will occur if your time series has the two-digit years 29 and 30. In this case 29 is read in as 2029, and 30 is read in as 1930. Note that data exported from Excel in *.csv format will be saved with the displayed date.
Both problems can be avoided by using the recommended ISO 8601 format to prevent ambiguity.
Predicted or calculated data
...