Welcome to CDEC A division of DWR

Most Popular Links

Related Links

Valid absolute date formats for data queries

    mm/dd/yyyy
    dd-mmm-yyyy
    mm-dd-yyyy
    yyyy.mm.dd
    yyyy_mm_dd
    mmddyy
    mm-dd
    mm/dd
     today
    now
Time may be appended after the date; e.g.
    mm/dd/yyyy hh:mm:ss
    mm/dd/yyyy hh:mm:ss     am pst
that is, you may optionally specify AM or PM or a time zone. Years may also be specified without the century (e.g. 12/1/85). If you omit the year, the present year is assumed.

Important! Monthly data is always indexed as the first of the month. This includes end-of-month reservoir storage and precipitation data. Therefore, storage for the end of the month of October, 1982 can be found under the date "10/82" or equivalently "10/1/82". The date "10/31/82" is not valid in this case--although that day is really when the data were taken.

Relative Date Examples

This is for the "span" or "going back" fields, to specify how far back you'd like to retrieve.

    1month
    24hours
    5days
    2days12hours
You may omit spaces, as shown in these examples.

Daylight Savings time

(Known outside the U.S. as Summer Time). Ah, time. This daylight savings time custom creates as many problems as it solves, no? The database stores time in Coordinated Universal Time, abbreviated UTC and known by the British and some Americans as GMT. It converts it to ``local'' time when you retrieve data, rather than when it is stored. We have our computer set up here in Sacramento, California, USA, which is in the Pacific Time Zone, denoted PST or PDT for Pacific Standard Time or Pacific Daylight [Savings] Time. (GMT-8). The computer running the database is configured to automatically handle PST and PDT transitions.

Consider data from June 6. From April-November, the computer's ``local time'' is PDT. If you retrieve data from June 6, the values, stored as UTC, are converted to PDT.

From about December-March, the computer's ``local time'' will be PST. If you retrieve data from June 6 during this period, the values, stored as UTC, will be converted to PST. Therefore, the results from your query for June 6 data will be different, depending on it being December or on June.

In 1996, the changeover occured early in the morning of April 6. If you retrieved data every few hours on April 6, time data would change before your eyes around 3 AM.

If we moved the database to Colorado, all the data would be shifted an additional hour, since it would be retrieved as MDT. For example, the peak river stage at Vina Woodson Bridge on January 10 occured at 09:00 PST. Executing a query in July after hypothetically moving the computer to Colorado would show the peak occurring on January 10 at 11:00 MDT.

I think this is the best way to handle the situation. In nature, there are no actual gaps or overlaps in the data stream; one hour follows the next.