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
...
| icon | false |
|---|
...
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.
The TIME framework will always write dates in the following format and it is recommended that you follow the same format and use zero padding within dates. For example, "2000-01-02" is preferred over "2000-1-1" to avoid ambiguity:
...
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
...