When implementing the StringCell, KNIME provides a convenience access member ‘TYPE’:
/**
* Convenience access member for
* <code>DataType.getType(StringCell.class)</code>.
*
* @see DataType#getType(Class)
*/
public static final DataType TYPE = DataType.getType(StringCell.class);
But for the LocalDataCell this member is not public:
/** {@link DataType} of this cell. */
static final DataType TYPE = DataType.getType(LocalDateCell.class);
I actually love using the convenient TYPE member as I machine-generate my output specifications. So it would be great if you could also make the LocalDataCell public!
I’m just starting to dig into the new Dates and Times and didn’t appreciate how much extra work there is in handling all of the different types: LocalDate, LocalTime, LocalDateTime, and ZonedDateTime. I miss the old days when there was only one type of DateAndTime. Is there a “universal” KNIME date-time data type that accepts any input column when the distinction between local / zoned / with-time / without-time isn’t important?
The LocalDateCellFactory class provides this public TYPE member you are searching for. There is also the method #getDataType which all data cell factories provide.
Well, there is the deprecated DateAndTimeCell. However, the date and time topic is very complex and a type which allows you to handle all different kinds of dates and times may be very convenient for the user, but not transparent at all, e.g. if you want to shift all the cells in such a column by one hour, what should happen if there is a cell without a time? Why should a time without a date and a date without time actually be of the same type? They cannot be processed the same way. This has been a problem for a long time in the Java world and, thus, also in the KNIME world. With Java 8, the date and time topic was finally revised and we integrated it into KNIME. As a developer, it is actually easier to work with the new types since you can make assumptions about the types and their content. Additionally, the new types provide much more functionality which saves you a lot of work.
If you need help developing with the new date and time cells, let me know! It can be confusing at the beginning, but debugging will make a lot more fun.
Thanks Simon! I had just made that same discovery about the LocalDateCellFactory.TYPE.
I’m now running into more new stuff with the LocalDate. For example, I thought I could create a new LocalDate output cell the same way I’ve been doing it for Strings, Doubles, Integers, etc:
new StringCell( myString )
new LocalDateCell( myDate )
But the LocalDateCell is also not visible. Looks like I need to use the factory for that as well:
LocalDateCellFactory.create( myDate )
I’m beginning to appreciate the flexibility and the power of the Java 8 time and date and suspect that you are right - it will ultimately prove to be easier to work with.
For sake of backwards compatibility, we need to keep the constructors of the “old” cell types public, but using the factories to create new cells should be also the preferred way for all the other cells.
The multitude of types is definitely more work at first, but actually it saves some very awkward issues with the old Date and Time cells - particularly, for example when you have e.g. a pair of dates which fall on or over a daylight saving time boundary in your local timezone, particularly if your input strings have the time arbitrarily set as +00:00 as is quite often the case, whereby you can end up with a date being on the “wrong” day as a result!