Opened 14 years ago
Last modified 14 years ago
#1512 closed enhancement
Add support for datetime annotation types — at Version 4
Reported by: | Nicklas Nordborg | Owned by: | Nicklas Nordborg |
---|---|---|---|
Priority: | major | Milestone: | BASE 2.16 |
Component: | core | Version: | |
Keywords: | Cc: |
Description (last modified by )
This is a rather big change and will have effect in other parts of BASE as well. Here is a list of things that we need to do.
- Add a new table for storing datetime values and a subclass to
ParameterValues
to handle it. - Add a new option to the
Type
enumeration. - Update the gui so that it is possible to add datetime values
- Update the query api so that it is possible to search for datetime values
- There are probably some effects also on the plug-in api since the
Type
enumeration andParameterValues
class are used by plug-in parameters as well. I'll have to investigate the effect and maybe add a specific ticket for adding datetime support to the plug-in system if the work required is substantial. - There may be similar effects on "extendable" classes (eg. reporters, users and raw data).
- Check and update documentation
- More...?
Change History (4)
comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Oh no... what a mess... I have to correct myself on the previous comment. It is possible to store datetime values with the current BASE release and it is not very complicated.
By changing the BASE->Preferences->Date format
setting to a template that includes time placeholders (for example yyyy-MM-dd hh:mm:ss
) it is possible to enter datetime values and the time part will be parsed and stored in the database. It messes up the query api though, since it will not match anything if not the exact date+time (including seconds) is entered as a search condition. Other users that hasn't changed the 'Date format' option will not be able to find any datetime values at all (except 00:00:00) since the time part is discarded before the query is made.
I think the "mess" needs to be cleaned up and they best way to do that is to make sure that no time part is getting into date-only values. Eg. we need one table for storing date-only values and one table for storing datetime values.
comment:4 by , 14 years ago
Description: | modified (diff) |
---|
Hmm... it seems like the table used to store dates is actually using a 'timestamp' column so theoretically it should be possible to use the existing table to store datetime values. And some (but not all) parts of the core api already allows the time part to be stored for date values. The main exception is that all string conversions to/from dates don't handle time and most of the gui is about string handling. I am trying to figure out what is the best:
The latter is "cleaner" and is more correct according to the current documentation. The ability to store the 'time' part can be considered a bug. On the other hand, converting the existing table is an incompatible change which will cause data loss if someone is storing datetimes in it. It's not that likely though, since it can't happen with the official BASE release.