From dev-return-18473-archive-asf-public=cust-asf.ponee.io@manifoldcf.apache.org Thu Sep 20 10:58:09 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 03926180671 for ; Thu, 20 Sep 2018 10:58:08 +0200 (CEST) Received: (qmail 89483 invoked by uid 500); 20 Sep 2018 08:58:03 -0000 Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@manifoldcf.apache.org Delivered-To: mailing list dev@manifoldcf.apache.org Received: (qmail 89468 invoked by uid 99); 20 Sep 2018 08:58:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Sep 2018 08:58:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id B5D591A02CF for ; Thu, 20 Sep 2018 08:58:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 2arUn0XiUc_R for ; Thu, 20 Sep 2018 08:58:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 6B17D5F433 for ; Thu, 20 Sep 2018 08:58:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CF190E0360 for ; Thu, 20 Sep 2018 08:58:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4136B23F9C for ; Thu, 20 Sep 2018 08:58:00 +0000 (UTC) Date: Thu, 20 Sep 2018 08:58:00 +0000 (UTC) From: "Karl Wright (JIRA)" To: dev@manifoldcf.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CONNECTORS-1521) Documentum Connector users ManifoldCF's local time in queries constraints against the Documentum server without reference to time zones MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CONNECTORS-1521?page=3Dcom.atl= assian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-1521: ------------------------------------ Fix Version/s: ManifoldCF 2.12 > Documentum Connector users ManifoldCF's local time in queries constraints= against the Documentum server without reference to time zones > -------------------------------------------------------------------------= -------------------------------------------------------------- > > Key: CONNECTORS-1521 > URL: https://issues.apache.org/jira/browse/CONNECTORS-152= 1 > Project: ManifoldCF > Issue Type: Bug > Components: Documentum connector > Affects Versions: ManifoldCF 2.10 > Reporter: James Thomas > Assignee: Karl Wright > Priority: Major > Fix For: ManifoldCF 2.12 > > > I find that the time/date constraints in queries to the Documentum server= are based on the "raw" local time of the ManifoldCF server but appear to t= ake no account of the time zones of the two servers. > This can lead to recently modified files not being transferred to the out= put repository when you would naturally expect them to be. I'd like the tim= es to be aligned, perhaps by including time zone in the query. In particula= r, is there a way to use UTC perhaps? > Here's an example ... > * create a folder in Documentum > * set up a job to point at the folder and output to the file system > * put two documents into a folder in Documentum > * Select them, right click and export as CSV (to show the timestamps): > {noformat} > 1.png,48489.0,Portable Network Graphics,8/7/2018 9:04 AM, > 2.png,28620.0,Portable Network Graphics,8/7/2018 9:04 AM,,{noformat} > Check the local time on the ManifoldCF server machine. Observe that it's = reporting consistent time with the DM server: > {noformat} > [james@manifold]$ date > Tue Aug=C2=A0 7 09:07:25 BST 2018{noformat} > Start the job and look for the query to Documentum in the manifoldcf.log = file (line break added for readability): > {noformat} > DEBUG 2018-08-07T08:07:47.297Z (Startup thread) - DCTM: About to execute = query=3D (select for READ distinct i_chronicle_id from dm_document where r_= modify_date >=3D date('01/01/1970 00:00:00','mm/dd/yyyy hh:mi:ss') and > r_modify_date<=3Ddate('08/07/2018 08:07:34','mm/dd/yyyy hh:mi:ss')=20 > AND (i_is_deleted=3DTRUE Or (i_is_deleted=3DFALSE AND a_full_text=3DTRUE = AND r_content_size>0)) AND ( Folder('/Administrator/james', DESCEND) )) > ^C{noformat} > Notice that the latest date asked for is *before* the modification date o= f the files added to DM. (And is an hour out, see footnote.) > =C2=A0 > See whether anything has been output by the File System connector. It ha= sn't: > {noformat} > [james@manifold]$ ls /bigdisc/source/PDFs/timezones/ > [james@manifold]$ > {noformat} > Now: > * change the timezone on the ManifoldCF server machine > * restart the ManifoldCF server and the Documentum processes > * reseed the job > Check the local time on the ManifoldCF server machine; it has changed: > {noformat} > [james@manifold]$ date > Tue Aug=C2=A0 7 10:10:29 CEST 2018{noformat} > Start the job again and notice that the query has changed by an hour, plu= s the few minutes it took to change the date etc (and is still an hour out,= see footnote): > {noformat} > r_modify_date<=3Ddate('08/07/2018 09:11:02','mm/dd/yyyy hh:mi:ss')=20 > {noformat} > Observe that the range of dates now covers the timestamps on the DM data,= and also that some data has now been transferred by the File System connec= tor: > {noformat} > [james@manifold]$ ls /bigdisc/source/PDFs/timezones/http/mfserver\:8080/d= a/component/ > drl?versionLabel=3DCURRENT&objectId=3D090000018000e515 > drl?versionLabel=3DCURRENT&objectId=3D090000018000e516 > {noformat} > =C2=A0 > =C2=A0 > [Footnote] It appears that something is trying to take account of Dayligh= t Saving Time too. > If I set the server date to a time outside of DST, the query is aligned w= ith the current time: > {noformat} > [i2e@i2ehost manifold]$ date > Mon Oct 29 00:01:13 CET 2018 > r_modify_date<=3Ddate('10/29/2018 00:01:39','mm/dd/yyyy hh:mi:ss')=20 > {noformat} > But if I set the time inside DST, the time is an hour before: > {noformat} > [i2e@i2ehost manifold]$ date > Sat Oct 27 00:00:06 CEST 2018 > r_modify_date<=3Ddate('10/26/2018 23:00:26','mm/dd/yyyy hh:mi:ss')=20 > {noformat} > This is perhaps a Java issue rather than a logic issue in the connector? = See e.g. [https://stackoverflow.com/questions/6392/java-time-zone-is-messed= -up] -- This message was sent by Atlassian JIRA (v7.6.3#76005)