Menu

Partially qualified ISO String parsing / handling

2013-07-05
2013-07-05
  • Jochen Kohler

    Jochen Kohler - 2013-07-05

    Hi There !

    I do have a problem which I liked to solve using joda-time. Unfortunately, after a few days of reading / trying, I'm nowhere near a solution. So I thought about posting my Problem here in order to find out if it possible to solve it using joda-time.

    What I have to do:
    I do have an application that receives XML based messages which contain ISO date strings. These Strings may refer to a particular instant, but may as well only refer to a day without time, a month in a year or something else partially qualified.
    This ISO date string shall be stored in the database with additional meta information to help with ranged queries directly in the database.
    I want to store:
    - the iso date string
    - the timezone seperately
    - the lower bound for this iso date (for "2013-04-17", this would be 2013-04-17T00:00:00,000)
    - the upper bound for this iso date (for "2013-04-17", this would be 2013-04-17T23:59:59,999)
    - the percision of the iso date string (for "2013-04-17", I'd expect something like [year, monthOfYear, dayOfMonth])

    What I tried so far ...
    1.) I used DateTime.parse(String) in order to parse my ISODate string, which returns me a perfectly valid DateTime Object that represents an Instant (for "2013-04-17", this is in fact my lower bound [2013-04-17T00:00:00,000]). Unfortunately, I couldn't find out which values are 0 because the ISO date String contained that value or because that is the default for this instant.
    -> Since I can't decide based on which fields I have to compute my boundaries, that doesn't work.

    2.) I tried LocalDateTime.parse(String).getFieldTypes() to find out which fields have been parsed. That returns [year, monthOfYear, dayOfMonth, millisOfDay] independent of the percision of the time contained in the ISO date String.
    -> again, since I can't decide based on which fields I have to compute my boundaries, that doesn't work.

    3.) While browsing thru the source code and debugging a bit, I found that there is something called a DateTimeParserBucket, which is used in the DateTimeFormatter while parsing. This calls holds exactly the information I am looking for in a private Array of SavedFields. This Array tells me exactly what I need ... or rather it would, if I could access it somehow. Since the ISODateTimeFormatter creates the used bucket on the fly as a local variable in the parseMethod, I copied the class to my SourceTree and created the Bucket into an instance variable, to be able to access it after the parsing is finished. But since the Type SavedField is package private, I can't get the information I want (not even reading the content using reflection).
    -> the information is there, I can see it in the debugger, but I can't reach it.

    4.) While debugging I stumbled over the parseInto(ReadWritableInstant, String, pos) Method. The Javadoc read jolly good, so I gave it a try using an instance of MutableDateTime. Creating a MutableDateTime prefills the object with the current time, which is bad for me. So I decided to create an instance using invalid values to identify them later (Integer.MIN_VALUE for every field). That is impossible, since the MutableDateTime does only accept valid values for the particular fields (which is a brilliant feature for almost all use cases I can think of except mine ;-) ). Now I can't initialize the instance wihout giving it default values.
    -> again, since I can't determine which fields have been filled based on the ISO date String, I can't compute my boundaries

    That's basically my current state of affairs ... and I am at my wits end on a friday afternoon.

    I would really appreciate if somebody could tell me if there is a solution to my problem (and I am just to dumb to find it), and in case there is, a hint what I am doing wrong.

    Last but not least, nothing I write here is meant as a complaint. I do see that joda-time is a highly sophisticated library to handle dates. This is the reason why I want to utilize it to solve my problem instead of trying (and probably failing) to implement it on my own. So basically, no offence meant ... :-)

    Thanks in advance,
    Jochen

     
  • Stephen Colebourne

    You've pretty much investigated all the options. Joda-Time is designed to give you a complete answer, not a partial one. Thus the best you can do is to parse in a loop until something succeeds, and use that to determine the fields.

    In JSR-310 you can access the underlying parsed fields :-)

     

Log in to post a comment.