Date support

[Radovan Semancik]

Hi,

The framework is completely missing support for date and time data
types. The old LDAP connector is using long instead. This is a major
issue. Date and time data are quite important in the IDM, and now the
IDM cannot distinguish which data fields are datetime and which are just
ordinary long integers.

The problem is that the datetime-related classes are a real mess in
Java. There are libraries that provide a more reasonable API, but I do
not think that adding a dependency on of these is a good idea. Therefore
I propose to simply add support for java.util.Data as a primitive ConnId
data type. And we will use it simply as a wrapper for time in millis
(long). But, having it as a java.util.Date will give us ability to
distinguish it as a date/time value and also ability to express it in
the schema.

--
Radovan Semancik
Software Architect
evolveum.com

[Francesco Chicchiriccò]

Not bad; the only problems with java.util.Date are about troublesome
timezone support.

I guess you are referring to 3rd party libraries as Joda-Time [1] which
would be far more usable but also violate the "as less dependencies as
possible" principle.

Regards.

[1] http://www.joda.org/joda-time/

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/

[Radovan Semancik]

On 06/03/2015 09:40 AM, Francesco Chicchiriccò wrote:
> Not bad; the only problems with java.util.Date are about troublesome
> timezone support.

Yes. It is also mutable. But there is no perfect solution when it comes
to date/time and Java core classes :-) ... So I think that having Date
and just use "new Date(millis)" and date.getTime() is the least evil.
The time in millis is timezone-agnostic.

Alternatively we can create our own DateTime class that would be real
immutable wrapper for time in millis. I would like that solution as
well. But I'm a bit afraid that this would only add to the existing
dateTime confusion in Java. What do you think?

> I guess you are referring to 3rd party libraries as Joda-Time [1]
> which would be far more usable but also violate the "as less
> dependencies as possible" principle.

Exactly.

[László Hordós]

I prefer Francesco's suggestion to keep the framework API simple as possible. The DateTime is just a number or string and it's very different in Java and .Net so when it's serialised over the network it must be brought into a common format. We use a utility class to bring Java and .Net time to a common long value or ISO 8601 string format. I also remember your comment [1]  when I proposed the same since then I prefer keep the supported types simple or even simpler. In your system I guess you would probably prefer the XMLGregorianCalendar format. 

[1] https://bugster.forgerock.org/jira/browse/OPENICF-3?focusedCommentId=13322&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13322

--
You received this message because you are subscribed to the Google Groups "connid-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+...@googlegroups.com.
Visit this group at http://groups.google.com/group/connid-dev.
For more options, visit https://groups.google.com/d/optout.

[Radovan Semancik]

On 06/03/2015 09:56 AM, László Hordós wrote:

I prefer Francesco's suggestion to keep the framework API simple as possible. The DateTime is just a number or string and it's very different in Java and .Net so when it's serialised over the network it must be brought into a common format. We use a utility class to bring Java and .Net time to a common long value or ISO 8601 string format. I also remember your comment [1]  when I proposed the same since then I prefer keep the supported types simple or even simpler. In your system I guess you would probably prefer the XMLGregorianCalendar format. 

[1] https://bugster.forgerock.org/jira/browse/OPENICF-3?focusedCommentId=13322&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13322

Yes, keeping the framework simple is a good thing. But datetime is not a weak type and it is used quite frequently, e.g. metadata (such as create timestamp), password expiration dates, last login timestamp, hire/fire dates, ...

Yes, we are using XMLGregorianCalendar in midPoint. But I do not ask to support this. Having time in millis is OK for me. I can convert it as needed. But I must know that is it a timestamp and not ordinary long integer. Otherwise I do not know that I have to convert it. As the framework specifies attribute types by using Java classes then we need a Java class to represent that. And it looks like java.util.Date is the least evil to wrap time in millis in a Java class.

If you do not like this then there are alternatives. The ugly and brutal is to add a flag in AttributeInfo that will mark it as a timestamp. Or we can add new property to AttributeInfo that will specify the type in some established type system (e.g. xsdType). But I do not like any of these. Too ugly, too complex. Support for java.util.Date (or a custom wrapper) seems to be better.

[Francesco Chicchiriccò]

I like the idea of a wrapper object as suggested by Radovan:

our own DateTime class that would be real immutable wrapper for time in millis

but I would rather see it as a wrapper for actual timestamp internally represented as ISO 8601 string (naturally managed exclusively via JDK classes): this should also retain the compatibility with .Net.

WDYT?

[Radovan Semancik]

On 06/03/2015 11:16 AM, Francesco Chicchiriccò wrote:

I like the idea of a wrapper object as suggested by Radovan:

our own DateTime class that would be real immutable wrapper for time in millis

OK. I can live with that :-)

but I would rather see it as a wrapper for actual timestamp internally represented as ISO 8601 string (naturally managed exclusively via JDK classes): this should also retain the compatibility with .Net.

I do not think that this is really important. Any reasonable format will do. What lead me to suggest time in millis instead of ISO8601 is that the time in millis is currently used by the LDAP connector, but also by operational attributes such as ENABLE_DATE. We are bound to keep framework compatible, therefore we cannot really change the definition of ENABLE_DATE. It has to remain "long". But this is not really a problem, because ENABLE_DATE and other operational attribute are special and they require special handling anyway. But if the new wrapper used "long" internally then the code change would be easier - both in framework and in clients. And correct me if I'm wrong, but the internal format of the date does not really matter. Connectors see it as Java (or .NET) object. So it only matters for remote connector communication. Right?

[Francesco Chicchiriccò]

That's true: let's then downsize the requirements to (i) safely transport Date objects and (ii) retain compatibility between Java and .Net.
To me, any proposal having these as reference is acceptable.

Regards.

[Francesco Chicchiriccò]

Guys, any update about this topic?

[Radovan Semancik]

On 06/19/2015 01:22 PM, Francesco Chicchiriccò wrote:
> Guys, any update about this topic?

I'm sorry. Haven't had much time for this. Auxiliary object classes got
higher priority.

But anyway, I would like to see Laszlo's opinion before I get into this.

For me this is a problem. But not a big problem. We can move it out of
1.4.2 release if needed.