Colega, é o seguinte : é AMPLAMENTE documentado nos manuais Oracle que SYSDATE retorna a data do Sistema Operacional, que é ÚNICA, *** E *** que essa função interna retorna um datatype DATE, que ABSOLUTAMENTE NÃO DÁ suporte a time zones, então não é que "particularmente não é o correto" : se o Aplicativo é (ou deveria ser...) multi-país/multi-fuso horário o SYSDATE sozinho é ABSOLUTAMENTE, TOTALMENTE, COMPLETAMENTE errado, vc tem um bug do tamanho dum 747 aí NO SEU CÓDIGO, e bug vc corrige ALTERANDO O CÓDIGO, ponto... Eu disse "sysdate sozinho" porque, antes de ser criado pela Oracle o suporte à timezone no bd, o que a gente fazia é ter uma tabela de TZ e escrever uma funçãozinha DATA_HOJE que a lê e retorna o SYSDATE somado/ubstraído o TZ., e usava a DATA_HOJE em lugar de SYSDATE... Não tem mágica aí não, ok ? Vamos ver o que o pessoal que mexe com Java diz, mas imagino que no seu aplicativo a SYSDATE está sendo usada tanto para alimentar variáveis/itens nos seus programas Java quanto em SQLs (tipo INSERT INTO tabela (..., SYSDATE, valores, etc) , então penso que :
a) MESMO que haja um setting dizendo pro Java "ah, variáveis / itens com datatype DATE vc adicione x horas por conta de fuso", mesmo assim isso NÂO deve ser nada "automático", é ALTERAÇÂO do código, sim e b) Óbvio que se a existir ele ** NÃO ** vai automagicamente alterar os SQLs que chamam SYSDATE, isso é (novamente) alteração de código a alteração imho é simples, é aonde estiver escrito SYSDATE vc substituir por uma funçãozinha sua que leva em conta o TZ, ou usar a CONVERT como eu disse, ou usar a SYSTIMESTAMP ou similares (se o sistema aceitar datatype TIMESTAMP com time zone ao invés de DATE), mas Alterar será inescapável, penso eu... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "fcm177" <fcm...@...> escreveu > > Chiappa e Colegas de Plantão e Pessoal de JAVA > > Pensando na Estrategia de Centralizar todos os Paises em uma nuvem de > Processamento (Oracle RAC) ao qual estaria medindo de uma maneira mais > organizada os consumos de cada Pais e o quanto poderia aumentar de recursos > conforme a demanda requerida, tendo como fator IMPEDITIVO o fato de a > Aplicação usar o SYSDATE (que particularmente não é o correto dependendo do > seu pais, pois o SYSDATE vai estar apontando para o Sistema Operacional ....) > para abertura e termino de pregão, cotações daquele pais com seu respectivo > horario , praticamente se torna impossivel e inviável via Oracle BD RAC fazer > isto ...., a não ser que modifique o Codigo da Aplicação Java ? Será que não > existe outra maneira , talvez de mudar entao de SYSDATE para outra > COLUNA_DATA_A_NIVEL_SESSAO ....., para que ele enxergue a data e horario do > seu Pais .., por exemplo , configurar via SESSAO ou via SERVICO criado no RAC > , para que todos aqueles que conectem por este SERVICO consiga obter um > horario da Espanha ? por exemplo .... > > Pessoal de Java, com excessão desta situação, via Java existe algum modo > facil que podemos tratar isto tambem ......? > > Obrigado a todos ..... > > Fernando >