Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-3171

jcr:created property on node has wrong time zone set

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Not a Problem
    • Affects Version/s: 2.2.9
    • Fix Version/s: None
    • Component/s: jackrabbit-core
    • Labels:
      None
    • Environment:
      Linux

      Description

      I would expect that default time zone is set when jcr:created property is created by Jackrabbit for node. But I see following:

      Default time zone: sun.util.calendar.ZoneInfo[id="Europe/Prague",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=141,lastRule=java.util.SimpleTimeZone[id=Europe/Prague,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]

      Time zone from Calendar instance: sun.util.calendar.ZoneInfo[id="GMT+01:00",offset=3600000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

      Is it possible to control time zone set to property jcr:created? Any hint where time zone is set for jcr:created property would be appreciated so that I can investigate in my environment.

        Activity

        Hide
        Alexander Klimetschek added a comment - - edited

        That's correct. The JCR date does not store the full timezone ID (such as "Europe/Prague" in your example), but only the offset. This is because internally the date is stored as ISO 8601 string, which does not keep the ID. That's per spec [0] (unfortunately).

        Hence after reading that string again, it will use the simple offset based IDs, such as GMT+01:00 in your case.

        If you need to keep the ID, you need to store it in a separate string property.

        [0] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.4.3%20From%20DATE%20To

        Show
        Alexander Klimetschek added a comment - - edited That's correct. The JCR date does not store the full timezone ID (such as "Europe/Prague" in your example), but only the offset. This is because internally the date is stored as ISO 8601 string, which does not keep the ID. That's per spec [0] (unfortunately). Hence after reading that string again, it will use the simple offset based IDs, such as GMT+01:00 in your case. If you need to keep the ID, you need to store it in a separate string property. [0] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.4.3%20From%20DATE%20To

          People

          • Assignee:
            Unassigned
            Reporter:
            Marek Slama
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development