On 23.08.2020 20:25, Michaud Michael wrote: > Ede, > > Broken tests : my feeling is that FlexibleDateParser is doing too much (more > than hundred different formats).
surely is. my point merely is that if testing, as in the test case June 1970 June 19 than the order MMMM dd MMMM yyyy is important so 'June 19' is not matched with 'MMMM yyyy'. it's a corner case, still i have the feeling that the formats were ordered that way with intent. > Wonder if it wouln't be better to have a parser > with less formats (removing ambiguous formats like dd/MM, MM/dd, MM/yy, yy/MM > etc.) and add a mechanism to use a user-defined parser where it is needed (we > already have one in options panel for table attribute display). We could also > add a plugin to change a String attribute to a Date attribute with an ad'hoc > parser (most databases have a set of specific functions to handle dates and > times) not sure what you mean here. how would you use database functions to modify feature attributes? and as that would be database specific, wouldn't it be a kind of complex? > Yes I saw the code of sqlite driver. Seems that I changed the code from > getDate > to getTimestamp in 2013 with the following comment : "fix 1472782 : date is > now > shown with time in attribute table. It is persisted as timestamp in postgis > database and jml files, but time part is still lost in shapefiles." Possible > because both sql.Date and sql.Timestamp are subclasses of java.util.Date. > Currently, the code is the same for all the drivers. > > Maybe we can do better using getDate or getTimestamp depending on the jdbc > type, > but I would wait for an actual problem before modifying this code. > > The problem I found in sqlite driver is that attributes declared as TIMESTAMP > but stored as text does not return java.sql.Timestamp but varchar so that our > code just read it as String and store it as AttributeType.STRING > (https://github.com/xerial/sqlite-jdbc/issues/532) well, sqlite JDBC's getDate() handles string columns for dates. timestamps still have to be SQLITE_FLOAT or SQLITE_INTEGER. how did you manage to save the date column as text? was it intentionally? we could easily add a check that tests for string containing only numbers and parsing it as timestamp, as a workaround. should be speedy enough. ..ede _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
