Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.1.2
    • Fix Version/s: 2.3
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The POM XSD defiens the TimeZone as an xs:string (although the descriptions says an integer between -11 and 12)

      If the desctription is enforced you can not be in a timezone that is not a multiple of 1 hour away from UTC (e.g. certain parts of india)

      So the description is wrong and it's just a String.
      So why not support a full formatted timezone such as Europe/London, then the mpir can use funky javascript to show your actual time including any daylight saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)

      e.g. support

      <developers>
        <developer>
          <id>bob</id>
          <name>Bob Hacker</name>
          <email>bob@example.com</email>
          <timezone>Europe/London</timezone>
          <roles>
            <role>developer</role>
          </roles>
        </developer>
      </developers>

      Currently the site shows NaN for the Current time.

        Issue Links

          Activity

          Hide
          Jerome Lacoste added a comment - - edited

          I've implemented a HTML version of the team-list that uses http://js.fleegix.org/plugins/date/date
          to support "String" timezones.

          See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

          the diff to the generated files is

          --- team-list.html	2009-11-23 23:38:37.000000000 +0100
          +++ team-list2.html	2009-11-24 11:22:10.000000000 +0100
          @@ -521,18 +521,28 @@
           </table>
           </div>
           </div>
          +<script type="text/javascript" src="scripts/fleegix.js"></script>
          +<script type="text/javascript" src="scripts/date.js"></script>
           <script type="text/javascript">
           function offsetDate(id, offset) {
          -    var now = new Date();
          -    var nowTime = now.getTime();
          -    var localOffset = now.getTimezoneOffset();
          -    var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 60 * 1000 );
          -    var developerDate = new Date(developerTime);
          -
          +    var developerDate;
          +    if (offset.indexOf('/') != -1) {
          +      var dt = new fleegix.date.Date();
          +      dt.setTimezone(offset);
          +      developerDate = new Date(dt);
          +    } else {
          +      var now = new Date();
          +      var nowTime = now.getTime();
          +      var localOffset = now.getTimezoneOffset();
          +      var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 60 * 1000 );
          +      developerDate = new Date(developerTime);
          +    }
               document.getElementById(id).innerHTML = developerDate;
           }
           
           function init(){
          +    fleegix.date.timezone.zoneFileBasePath = './tz/';
          +    fleegix.date.timezone.init();
               offsetDate('developer-0', '-5');
               offsetDate('developer-1', '+1');
               offsetDate('developer-3', '+1');
          

          general drawbacks of such a solution

          • the pages generate more traffic (javascripts, zoneInfo files)
          • zoneInfo values may not be valid in the future (pages may not work in some years if the tz isn't updated)

          the drawbacks of the current demo:

          • the zoneInfo files are not trimmed for space
          • we use a simple check to identify String timezones. Is it robust enough ?
          • there should probably be some try/catch to detect issues.

          Ideally the method offsetDate() should be renamed.

          Let me know if that seems interesting, and I can look into changing the code to support this.

          Show
          Jerome Lacoste added a comment - - edited I've implemented a HTML version of the team-list that uses http://js.fleegix.org/plugins/date/date to support "String" timezones. See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo the diff to the generated files is --- team-list.html 2009-11-23 23:38:37.000000000 +0100 +++ team-list2.html 2009-11-24 11:22:10.000000000 +0100 @@ -521,18 +521,28 @@ </table> </div> </div> +<script type= "text/javascript" src= "scripts/fleegix.js" ></script> +<script type= "text/javascript" src= "scripts/date.js" ></script> <script type= "text/javascript" > function offsetDate(id, offset) { - var now = new Date(); - var nowTime = now.getTime(); - var localOffset = now.getTimezoneOffset(); - var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 60 * 1000 ); - var developerDate = new Date(developerTime); - + var developerDate; + if (offset.indexOf('/') != -1) { + var dt = new fleegix.date.Date(); + dt.setTimezone(offset); + developerDate = new Date(dt); + } else { + var now = new Date(); + var nowTime = now.getTime(); + var localOffset = now.getTimezoneOffset(); + var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 60 * 1000 ); + developerDate = new Date(developerTime); + } document.getElementById(id).innerHTML = developerDate; } function init(){ + fleegix.date.timezone.zoneFileBasePath = './tz/'; + fleegix.date.timezone.init(); offsetDate('developer-0', '-5'); offsetDate('developer-1', '+1'); offsetDate('developer-3', '+1'); general drawbacks of such a solution the pages generate more traffic (javascripts, zoneInfo files) zoneInfo values may not be valid in the future (pages may not work in some years if the tz isn't updated) the drawbacks of the current demo: the zoneInfo files are not trimmed for space we use a simple check to identify String timezones. Is it robust enough ? there should probably be some try/catch to detect issues. Ideally the method offsetDate() should be renamed. Let me know if that seems interesting, and I can look into changing the code to support this.
          Hide
          Jerome Lacoste added a comment - - edited

          Looks like the new page doesn't work on my Firefox 3.5, but works in opera 10.01 and chromium 4.0.252.0. No error in the javascript console it seems...

          page tested and works in opera, ff and chromium. Problem was use of <script/> while page was identified as HTML (due to extension it seems) even if the doctype is XHTML. Thus the loading of the external scripts failed.
          Using <script></script> solves it.

          Show
          Jerome Lacoste added a comment - - edited Looks like the new page doesn't work on my Firefox 3.5, but works in opera 10.01 and chromium 4.0.252.0. No error in the javascript console it seems... page tested and works in opera, ff and chromium. Problem was use of <script/> while page was identified as HTML (due to extension it seems) even if the doctype is XHTML. Thus the loading of the external scripts failed. Using <script></script> solves it.
          Hide
          Anthony Whitford added a comment -

          I second the idea of using TimeZone values instead of an integer offset. The offset idea is flawed because it does not account for daylight savings. For example, consider the TimeZone "America/Los_Angeles": Los Angeles is in the Pacific Time Zone, which is GMT-8 during Standard Time and GMT-7 during Daylight Saving Time. Some time zones will not adjust for daylight savings. Finally, countries will change their time zone rules, specifically adjusting when they start and end daylight savings.

          Show
          Anthony Whitford added a comment - I second the idea of using TimeZone values instead of an integer offset. The offset idea is flawed because it does not account for daylight savings. For example, consider the TimeZone " America/Los_Angeles ": Los Angeles is in the Pacific Time Zone, which is GMT-8 during Standard Time and GMT-7 during Daylight Saving Time. Some time zones will not adjust for daylight savings. Finally, countries will change their time zone rules, specifically adjusting when they start and end daylight savings.
          Hide
          Vincent Siveton added a comment -

          I fixed the M3 POM description and updated the code in r1029846, snapshot deployed.

          Show
          Vincent Siveton added a comment - I fixed the M3 POM description and updated the code in r1029846, snapshot deployed.

            People

            • Assignee:
              Vincent Siveton
              Reporter:
              James Nord
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: