Product Ideas

14 Vote

Pass regional settings for date / time fields

PrizmDoc currently uses the system's regional settings to render date and time fields. An example of this is an email message. When rendering the header information, PrizmDoc will use the regional settings of the server rendering the document to determine the UTC offset to apply to the "Sent" or "Received" Date fields and render them accordingly.

When using PrizmDoc for eDiscovery review and rendering, it is often the case (almost every client) that documents may originate from or wish to be rendered in a timezone other than that of the system timezone.

An example:

I collect data from Perth (GMT+9), Sydney (GMT+11) and Auckland (GMT+13) for a legal review. These documents are hosted on a server in Sydney (GMT+11) and rendered using that system's regional settings (GMT+11). However, the people reviewing the documents are based in Perth (GMT+9) and they wish all documents to be rendered for both review and production in GMT+9. However, on the same environment I have reviewers based in Wellington (GMT+13) and Adelaide (GMT+10.5), who each want their documents to be rendered and displayed in their timezones.

It is not feasible or practical to set the regional setting on the server hosting PrizmDoc to the desired timezone, as multiple timezone outputs will exist.

Solution:

Accept a UTC offset parameter when passed a document for rendering

  • Guest
  • Jul 31 2017
  • Planned
  • Attach files
  • David Wilner commented
    3 Feb, 2021 04:33am

    Any update on this post?

  • Caleb Postlethwait commented
    1 Oct, 2019 02:08pm

    We noticed the issue with emails, but I would imagine any file type where you're taking dates from the header and displaying them in UTC would be nice to control the display of. At the moment, a UTC offset is what we're being asked for, but I could also see a date format being requested at some point in the future, and if you're going to be touching the code anyways might as well ask for that now. Although I guess if it's already been over 2 years since it was first requested and you have a soft date that is another 6+ months out, I won't hold my breath.

  • Mark Fears commented
    30 Sep, 2019 04:07pm

    In the description of this request, it mentions an email as an example. Do you want to be able to set the dates in all documents and not just emails? For example, an Excel spreadsheet which currently renders per the server's locale settings.

  • Mark Fears commented
    30 Sep, 2019 04:00pm

    We've had other high priority issues that have pushed this further out than we wanted. My best estimate at this point is Q2 2020. As always, this is a best guess and the roadmap is subject to change.

  • Caleb Postlethwait commented
    27 Sep, 2019 07:50pm

    We're hoping for this feature as well and it's now Q4 2019. Based on last post, this was expected by now. Any update on when this might be addressed?

     

    -Caleb

  • Mark Fears commented
    1 Aug, 2017 03:38pm

    Hi Blare,

    It's not in progress yet. We have it scheduled to start late this year and expect to deliver in Q1, 2018. We have a major release in Q4 which is consuming most resources from now until Q4. This is definitely something we want to add and that is the earliest available time that it can get scheduled.

    Regards,

    Mark Fears

  • Guest commented
    1 Aug, 2017 12:42am

    Hi Mark – thank you for updating the idea as “Planned”. Is this something that is currently already in progress? I have a few clients that would be keen to see this feature and one in particular that is pressing me for an ETA.

    Kind regards,

    Blare Sutton
    Chief Technology Officer
    edt.
    Full life cycle support for litigation & investigations.

    Email & Skype blare.sutton@discoveredt.com
    Direct +61 417 252 739
    LinkedIn linkedin.com/in/blaresutton/
    Remote Assistance https://remote.edt.blue

    www.discoveredt.com

  • +7