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
Any update on this post?
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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
Attachments Open full size
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
Attachments Open full size
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
Attachments Open full size