SimpleDateFormat: A reason for more open source freedom with Java?

SimpleDateFormat implements rfc 822 dateTime time zone information. Sadly xml schema does this a slightly different way. The following template for example

 new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ").format(date);

will produce a date like this

2005-06-12T10:32:00.000+0200

Whereas what I need for xml schema is

2005-06-12T10:32:00.000+02:00

It would be relatively easy to just make a copy of the SimpleDateFormat class, rename it to XSDDateFormat and make a few adjustments. Then I would have what I need. But the code is copyrighted by IBM, so it is probably untoucheable. Clearly rewriting the class itself and allowing it to keep its name would lead to a lot of confusion, and should not be allowed. But using the code itself should cause no one any harm, when clearly moved into a different class.

Of course this is not the whole story in the open source argument for Java, but it should be a consideration.

Update: I found XMLGregorianCalendar in the javax.xml.datatype package, and after some serious searching on the web, I found out how to use it. So here:

 GregorianCalendar gc = new GregorianCalendar(); 
  gc.setTimeInMillis(time.getTime()); 
  DatatypeFactory df = DatatypeFactory.newInstance(); 
  XMLGregorianCalendar xc = df.newXMLGregorianCalendar (gc);
 String ts = xc.toXMLFormat();

Kindof complicated really. But still, it works...

So what is the lesson now? That it is good that the code was not licenced liberally, because it forced me to find the right solution?

Comments:

back in 1997 I was remotely maintaining systems at airports across the US and UK. Working in multiple timezones it bacame important to have a portable date format. Looking forward to 2000 it also becamse clear that I would need to incorporate a four digit year.
I didnt want to simply use seconds since epoch and I wanted to be sure that come 2000 I could still sort numericly. Dealing with DBA's I frequently found files with DD-MM-YYYY or MM-DD-YYYY What I came up with was to use UTC as the time zone and YYYYMMDD.HHMMSS as the date.

20060531.113822
this allows for:

  • infinite years
  • max 99 months per year
  • max 99 days per month. (MM/DD doesnt do 0/0)
  • max 100 hours per day
  • max100 minutes per hour
  • max 100 seconds per minute.

    for a more portable datecode, the timezone could be inserted inplace of the decimal.
    However this would encourage people to not use UTC and
    would negate the ability to sort a directory of files numericly (sort -n)
    expressed with the date command we get:

    [7:41]Solaris(18)% /bin/date -u +%Y%m%d.%H%M%S
    20060531.114123


    the next logical step could be to use the gnu date builtin for UTC and iso-8601 timestamp:

    [7:41am]Solaris(19)% /usr/local/gnu/bin/date -uIseconds
    2006-05-31T11:41:24Z


    and, for those who insist on a local time in their logs:

    [7:41am]Solaris(20)% /usr/local/gnu/bin/date -Iseconds
    2006-05-31T07:41:35-0400


    this solves for local timezone usage in logfiles but still makes common storage break numerical sorting.

    Posted by MikeTLive on May 31, 2006 at 07:07 AM CEST #

  • Post a Comment:
    Comments are closed for this entry.
    About

    bblfish

    Search

    Archives
    « April 2014
    MonTueWedThuFriSatSun
     
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
        
           
    Today