[Log4j] Date de la trace lors de l'insertion en base

Bonjour à tous,

J'observe un décalage de deux heure entre l'heure de réalisation d'une action et l'heure écrite dans ma base de données.

Je réalise une action à 16h00, j'obtiens une trace immédiatement dans ma base de données mais elle est marquée comme ayant eu lieu à 14h00.

Dans mon fichier log4j.properties mes insertions en base sont réalisées via une requête SQL correspondante à l'information log4j.appender.JDBC.sql

Ma requête valorise le champs date par un CURRENT_TIMESTAMP.

Sur mon sgbd la requête select current_timestamp from dual me retourne le bon horaire.

Je ne m'explique donc pas comment je peux avoir ce décalage. Quelqu'un aurait il une idée pour en détecter l'origine?

on peux voir ton log4j.properties?

merci de ta réactivité. Voici :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90

# This is the configuring for logging displayed in the Application Server log4j.rootCategory=INFO, stdout, R   # Replace the line above if you want to put a log file into the directory # you start app server from # log4j.rootCategory=INFO, stdout, R   log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout   # Pattern to output the caller's file name and line number. log4j.appender.stdout.layout.ConversionPattern=[SAGESS] %p [%t] %c{1}.%M(%L) | %m%n   log4j.appender.R=org.apache.log4j.RollingFileAppender   # You can change this to be an absolute path or even an environment variable # If you're using an environment variable, you will have to set JAVA_OPTS # to contain this variables - for example in the catalina.sh or catalina.bat # file   log4j.appender.R.File=SAGESS.log   log4j.appender.R.MaxFileSize=100KB   # Don't keep a backup file log4j.appender.R.MaxBackupIndex=1   log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n   # Configuration for receiving e-mails when ERROR messages occur. #log4j.appender.mail=org.apache.log4j.net.SMTPAppender #log4j.appender.mail.To=@ERROR-MAILTO@ #log4j.appender.mail.From=@ERROR-MAILFROM@ #log4j.appender.mail.SMTPHost=@ERROR-MAILHOST@ #log4j.appender.mail.Threshold=ERROR ##log4j.appender.mail.BufferSize=1 #log4j.appender.mail.Subject=[@ERROR-SERVER@] @APPNAME@ Application Error   #log4j.appender.mail.layout=org.apache.log4j.PatternLayout #log4j.appender.mail.layout.ConversionPattern=%d %-5p %c %x - %m%n   # If programmed properly the most messages would be at DEBUG # and the least at FATAL. log4j.logger.fr.rsi=WARN   # Control logging for other open source packages log4j.logger.org.apache.struts=WARN log4j.logger.org.displaytag=ERROR log4j.logger.org.springframework=ERROR log4j.logger.fr.improve=ERROR   # All hibernate log output of "info" level or higher goes to stdout. # For more verbose logging, change the "info" to "debug" on the last line. log4j.logger.org.hibernate.ps.PreparedStatementCache=info log4j.logger.org.hibernate.transaction=info log4j.logger.org.hibernate=info   # Changing the log level to DEBUG will result in Hibernate generated # SQL to be logged. log4j.logger.org.hibernate.SQL=DEBUG   # Changing the log level to DEBUG will result in the PreparedStatement # bound variable values to be logged. log4j.logger.org.hibernate.type=info       # A1 is set to be a ConsoleAppender. log4j.appender.A1=org.apache.log4j.ConsoleAppender   # A1 uses PatternLayout. log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n   # TRACE access logs log4j.category.Traceacces=TRACE, JDBC, A3 # Pour tracer dans un fichier #log4j.category.Traceacces=TRACE, A3   log4j.appender.A3=org.apache.log4j.FileAppender log4j.appender.A3.file=TRACE_ACCES.log log4j.appender.A3.layout=org.apache.log4j.PatternLayout log4j.appender.A3.layout.ConversionPattern=%d %m%n   log4j.appender.JDBC=fr.rsi.sagess.web.trace.DataSourceAppender log4j.appender.JDBC.layout=org.apache.log4j.PatternLayout log4j.appender.JDBC.datasource=jdbc/MA_BASE log4j.appender.JDBC.sql=INSERT INTO TRACE(DATE_CONSULTATION, champs2, champs3, champs4, champs5, champs6, champs7, champs8) VALUES (CURRENT_TIMESTAMP, SUBSTR('%m', 1, INSTR('%m', '|', 1, 1) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 1) + 1, INSTR('%m', '|', 1, 2) - INSTR('%m', '|', 1, 1) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 2) + 1, INSTR('%m', '|', 1, 3) - INSTR('%m', '|', 1, 2) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 3) + 1, INSTR('%m', '|', 1, 4) - INSTR('%m', '|', 1, 3) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 4) + 1, INSTR('%m', '|', 1, 5) - INSTR('%m', '|', 1, 4) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 5) + 1, INSTR('%m', '|', 1, 6) - INSTR('%m', '|', 1, 5) - 1), SUBSTR('%m', INSTR('%m', '|', 1, 6) + 1))

---

Le type de la colonne dans la table est bien "TIMESTAMP WITH TIME ZONE"? La doc oracle de current_timestamp dis bien que ça retourne un timestamp + la timezone associée.

Si tu veux un truc indépendant des timezone, utilise une colonne de type timestamp et la valeur LOCALTIMESTAMP

Le champs DATE_CONSULTATION est simplement de type Date

Ca me parait étrange, car quand je tente de reproduire l'anomalie dans mon environnement de dev sous eclipse, en local sur ma machine mais la bdd sur serveur, j'ai bien ce décalage.

Si je tente de reproduire en passant par une version hébergée (websphere), attaquant la même bdd que l'environnement de dev, je ne reproduis par le décalage.

Et si je copie la requête sql de mon log4j et l'exécute directement via sqlplus, je ne reproduis pas non plus le décalage.

Je vais tester avec LOCALTIMESTAMP et voir si je peux l'utiliser, car j'ai des utilisateurs situés dans différents fuseaux horaires.

Merci pour l'aide, j'apprécie

la version hebergée sur le serveur ainsi que la version avec le client DB n'ont probablement pas des timezone de session identiques.

Utilise sysdate ou current_date pour un champ de type Date, inutile de rajouter des risques d'erreur en ajoutant des conversion de type :)

Ayant eu le même résultat avec LOCALTIMESTAMP qu'avec CURRENT_TIMESTAMP j'ai dans la foulée testé SYSDATE qui me sort un horaire sans décalage. Je vais voir pour le current_date dont tu parles.

Merci sincèrement pour ton aide, j'étais parti dans l'idée que l'origine était serait plus complexe que ça.