#645 daylight savings does not work in csv reader,

nikhilgupta10 imported these comments from Sourceforge: The user dchassin does not exist anymore. Therefore assigning this to afisher1. "dchassin": * status changed from new to accepted ,

"dchassin":Can we identify a model/csv pair the illustrate the actual vs. desired behavior. I'm not sure there's a problem with the code so much as a problem with the documentation.

In a related issue though, I would argue that the date/time format of the reader is highly sub-optimal and inconsistent with the rest of GridLAB-D and this may lead to the confusion. If the reader supported the standard DATETIME formats, then DST would be supported if desired. Specifically, we should parse date/time fields using the standard convert_{to,from}_timestamp routines before trying the special YY:MM:HH:MM:SS format.

Is that the desired solution?

"jcfuller":The posted SF forum highlights the problem:

https://sourceforge.net/projects/gridlab-d/forums/forum/842562/topic/6367612

specifically, there is no way to handle the November time repeat (2 am twice).

"dchassin": * milestone changed from Version 2.3 RC 1 to Version 3.0 RC 1

A proposed fix was submitted in changeset:3693 that allows the time field to be specified as a fully qualified timestamp (i.e., YYYY-MM-DD HH:MM:SS ZZZZ).

However, it seems likely from a casual code review that the weather class in the climate module actually cannot handle DST at all and no fix to the input will remedy some of the observed problems. The samples are stored as month/day/hour values in local time without recording whether those values have DST taken into account. There are some checks to see whether values repeat, which would fail if DST is not considered (e.g., 2am PST != 2am PDT). If this fix does not address the problem, the entire climate module will have to be reviewed to determine whether the current implementation needs to be redone to consider DST. The best way to do that is to store all date/time values as TIMESTAMP (in UTC) instead of using local time. I recommend postponing this to V3.0 RC1.

"dchassin":Questions regarding the distinction between DATETIME and TIMESTAMP have been hopefully addressed by additional wiki documentation regarding the differences between those two data types. See https://sourceforge.net/apps/mediawiki/gridlab-d/index.php?title=Xref:Time for a list of wiki documents relating to date/time operations.

"dchassin":Questions regarding the impact of timezones on schedule have been hopefully address by additional wiki documentation regarding the use of local time in determining schedule behavior. See https://sourceforge.net/apps/mediawiki/gridlab-d/index.php?title=Schedule for details.

"dchassin":The previous information should begin to address the questions raised in forum thread topic \csv_reader / climate verification. The remaining problems will be addressed if/when csv_reader is upgraded in V3.0.

"dchassin": * version changed from 2.3 to trunk ,

"dchassin": * status changed from accepted to assigned ,

"jcfuller": * status changed from assigned to closed

resolution set to fixed

Fixed in v2.3, but needs to be merged into trunk - see ticket 707.

nikhilgupta10 / GridLAB-D

#645 daylight savings does not work in csv reader, #2388