DataHoraECF - Incrementando um dia

[edsonmoretti]

Bom dia!

Durante esse mês notei que em alguns clientes está salvando a data errada, aumentando um dia na data da venda. Isso em vários clientes, seguindo um padrão de dias mas não todos os dias. Imagino que tenha algo com ano bissexto.

Com algumas pesquisas, no código do jACBrFramework, na class OleData.java e deixei da seguinte forma.

Método setDate(double dtSrc);

//<editor-fold defaultstate="collapsed" desc="OleDate Conversion Methods">
    @SuppressWarnings("empty-statement")
    private void setDate(double dtSrc) {
        // source code copied from MFC 4.21 and modified
        long nDaysAbsolute; // Number of days since 1/1/0
        long nSecsInDay; // Time in seconds since midnight
        long nMinutesInDay; // Minutes in day
        long n400Years; // Number of 400 year increments since 1/1/0
        long n400Century; // Century within 400 year block (0,1,2 or 3)
        long n4Years; // Number of 4 year increments since 1/1/0
        long n4Day; // Day within 4 year block
        // (0 is 1/1/yr1, 1460 is 12/31/yr4)
        long n4Yr; // Year within 4 year block (0,1,2 or 3)
        boolean bLeap4 = true; // TRUE if 4 year block includes leap year

        // values in terms of year month date.
        int tm_sec;
        int tm_min;
        int tm_hour;
        int tm_mday;
        int tm_mon;
        int tm_year;

        double dblDate = dtSrc; // temporary serial date
        // If a valid date, then this conversion should not overflow
        
        // Round to the second
        dblDate += ((dtSrc > 0.0) ? HALF_SECOND : -HALF_SECOND);
        // Add days from 1/1/0 to 12/30/1899
        nDaysAbsolute = (long) dblDate + 693959L;
        dblDate = Math.abs(dblDate);
        nSecsInDay = (long) ((dblDate - Math.floor(dblDate)) * 86400.);
        // Leap years every 4 yrs except centuries not multiples of 400.
        n400Years = nDaysAbsolute / 146097L;
        // Set nDaysAbsolute to day within 400-year block
        nDaysAbsolute %= 146097L;
        // -1 because first century has extra day
        n400Century = (nDaysAbsolute - 1) / 36524L;
        // Non-leap century
        if (n400Century != 0) {
            // Set nDaysAbsolute to day within centurY
            nDaysAbsolute = (nDaysAbsolute - 1) % 36524L;
            // +1 because 1st 4 year increment has 1460 days
            n4Years = (nDaysAbsolute + 1) / 1461L;
            if (n4Years != 0) {
                n4Day = (nDaysAbsolute + 1) % 1461L;
            } else {
                bLeap4 = false;
                n4Day = nDaysAbsolute;
            }
        } else {
            // Leap century - not special case!
            n4Years = nDaysAbsolute / 1461L;
            n4Day = nDaysAbsolute % 1461L;
        }
        if (bLeap4) {
            // -1 because first year has 366 days
            n4Yr = (n4Day - 1) / 365;
            if (n4Yr != 0) {
                n4Day = (n4Day - 1) % 365;
            }
        } else {
            n4Yr = n4Day / 365;
            n4Day %= 365;
        }
        tm_year = (int) (n400Years * 400 + n400Century * 100 + n4Years * 4 + n4Yr);
        // Handle leap year: before, on, and after Feb. 29.
        if (n4Yr == 0 && bLeap4 && n4Day == 59) {
            /* Feb. 29 */
            tm_mon = 2;
            tm_mday = 29;
        } else {
            if (n4Yr == 0 && bLeap4 && n4Day >= 59) {
                --n4Day;
            }
            // Make n4DaY a 1-based day of non-leap year and compute
            // month/day for everything but Feb. 29.
            ++n4Day;
            // Month number always >= n/32, so save some loop time */
            for (tm_mon = (int) ((n4Day >> 5) + 1); n4Day > rgMonthDays[tm_mon]; tm_mon++);
            tm_mday = (int) (n4Day - rgMonthDays[tm_mon - 1]);
        }

        if (nSecsInDay == 0) {
            tm_hour = tm_min = tm_sec = 0;
        } else {
            tm_sec = (int) (nSecsInDay % 60L);
            nMinutesInDay = nSecsInDay / 60L;
            tm_min = (int) (nMinutesInDay % 60);
            tm_hour = (int) (nMinutesInDay / 60);
        }
        Calendar c = Calendar.getInstance();
        c.set(Calendar.YEAR, tm_year);
        c.set(Calendar.MONTH, tm_mon - 1);
        c.set(Calendar.DAY_OF_MONTH, tm_mday);
        c.set(Calendar.HOUR, tm_hour);
        c.set(Calendar.MINUTE, tm_min);
        c.set(Calendar.SECOND, tm_sec);
        setTime(c.getTime().getTime());
//        setYear(tm_year - 1900);
//        setMonth(tm_mon - 1);
//        super.setDate(tm_mday); // resolves ambiguity
        // between OleDate.setDate and
        // java.util.Date.setDate
//        setHours(tm_hour);
//        setMinutes(tm_min);
//        setSeconds(tm_sec);
    }
//</editor-fold>

Método toDouble();

public double toDouble() {
        // source code copied from MFC 4.21 and modified.
        Calendar c = Calendar.getInstance();
        c.setTime(this);
        int wYear = c.get(Calendar.YEAR);
        int wMonth = c.get(Calendar.MONTH);
        int wDay = c.get(Calendar.DAY_OF_MONTH);
        int wHour = c.get(Calendar.HOUR);;
        int wMinute = c.get(Calendar.MINUTE);;
        int wSecond = c.get(Calendar.SECOND);;
        //  Check for leap year and set the number of days in the month
        boolean bLeapYear = ((wYear & 3) == 0) && ((wYear % 100) != 0 || (wYear % 400) == 0);
        // Cache the date in days and time in fractional days
        long nDate;
        double dblTime;
        //It is a valid date; make Jan 1, 1AD be 1
        nDate = wYear * 365L + wYear / 4 - wYear / 100 + wYear / 400 + rgMonthDays[wMonth - 1] + wDay;
        //  If leap year and it's before March, subtract 1:
        if (wMonth >= 2 && bLeapYear) {
            --nDate;
        }

        //  Offset so that 12/30/1899 is 0
        nDate -= 693959L;

        dblTime = (((long) wHour * 3600L)
                + // hrs in seconds
                ((long) wMinute * 60L)
                + // mins in seconds
                ((long) wSecond)) / 86400.;

        double dtDest = (double) nDate
                + ((nDate >= 0) ? dblTime : -dblTime);

        return dtDest;
    }

No caso do toDouble foi só removido variáveis sem uso e métodos deprecated

No setDate foi removido métodos deprecated e ajustado o increment do dia, esse ajuste eu tirei de "https://github.com/tbrandt77/janrufmonitor/blob/master/modules/outlook/src/de/janrufmonitor/repository/OutlookDate.java"

Caso alguém tenha o mesmo problema está ai, ao menos comigo até agora resolveu, qualquer problema que eu tiver, eu posto aqui.

[Rafael Dias]

post os arquivos modificados para serem avaliados.

[edsonmoretti]

blz, segue.

Agora só eu tive esse problema de retorno da data errada? ou fui o primeiro a notar esse ano, rsrs. vlw.

OleDate.java

[Rafael Dias]

Modificações enviada ao SVN.

[romulofs65]

Rafael, tenho que alterar o projeto todo. Fiz a alteração só da Classe OleDate.java e não funcionou. O Que falta?

[rpassos]

Boa tarde!

Também estou enfrentando este problema da data. Baixei uma nova versão do jAcbrFramework pelo svn e fiz a atualização das classes em meu projeto. Após efetuar esta atualização ele continua com a data errada e agora esta pegando a hora como 12. Ex: Fiz uma venda hoje 01/02/2016 as 16:46 e ele salvou como 02/02/2016 as 04:16.

 

então eu também atualizei a dll ACBrFramework64.dll e ele passou a nem ativar o ACBR dando o erro:

Error looking up function 'ECF_Create': Não foi possível encontrar o procedimento especifico.

Ele esta apontando para esta linha no meu codigo

aCBrECF.setModelo(Integer.valueOf(configuracao.getImpressora().getModeloACBr())

que neste caso o modelo ACBr é 2

[romulofs65]

Consegui resolver o problema, alterando o método setDate conforme abaixo:    

    private void setDate(double dtSrc) {
        setTime(HSSFDateUtil.getJavaDate(dtSrc).getTime());
    }
    

 

Aqui também:

  public static double toOADate(Date date) {
        if (date == null) {
            return 0d;
        }
        return HSSFDateUtil.getExcelDate(date);
    }

 

Ambas modificações no OleDate.java

[edsonmoretti]

Em 01/02/2016 at 14:14, romulofs65 disse:

Rafael, tenho que alterar o projeto todo. Fiz a alteração só da Classe OleDate.java e não funcionou. O Que falta?

 

22 horas atrás, rpassos disse:

Boa tarde!

Também estou enfrentando este problema da data. Baixei uma nova versão do jAcbrFramework pelo svn e fiz a atualização das classes em meu projeto. Após efetuar esta atualização ele continua com a data errada e agora esta pegando a hora como 12. Ex: Fiz uma venda hoje 01/02/2016 as 16:46 e ele salvou como 02/02/2016 as 04:16.

 

então eu também atualizei a dll ACBrFramework64.dll e ele passou a nem ativar o ACBR dando o erro:

Error looking up function 'ECF_Create': Não foi possível encontrar o procedimento especifico.

Ele esta apontando para esta linha no meu codigo

aCBrECF.setModelo(Integer.valueOf(configuracao.getImpressora().getModeloACBr())

que neste caso o modelo ACBr é 2

 

22 horas atrás, romulofs65 disse:

Consegui resolver o problema, alterando o método setDate conforme abaixo:    

    private void setDate(double dtSrc) {
        setTime(HSSFDateUtil.getJavaDate(dtSrc).getTime());
    }
    

 

Aqui também:

  public static double toOADate(Date date) {
        if (date == null) {
            return 0d;
        }
        return HSSFDateUtil.getExcelDate(date);
    }

 

Ambas modificações no OleDate.java

Opa, desculpem gente, foi um equivoco. Alterem a linha (161):
 

c.set(Calendar.HOUR, tm_hour);

Para

c.set(Calendar.HOUR_OF_DAY, tm_hour);

Apenas isso resolve.

no java doc (HOUR)

"Número de campo para get e set indicando a hora da manhã ou da tarde. Horas é usado para o relógio de 12 horas (0 - 11). Meio-dia e meia-noite são representados por 0, não por 12. por exemplo, às 10: 04: 15,250 PM da hora é 10."

Dessa forma estava setando sem dizer AM ou PM

Sendo o certo:

(HOUR_OF_DAY)

"Número de campo para get e set que indica a hora do dia. HOUR_OF_DAY é usado para o relógio de 24 horas. Por exemplo, às 10: 04: 15,250 PM o HOUR_OF_DAY é de 22."

Segue anexo para SVN.

por não está setando AM | PM ao virar o relógio de 12 >> incrementava mais um dia, e a hora por não setar o formato 24 para o java ficava sempre com diferença de 12h por meio período.

Um abraço.

OleDate.java

Editado 2 Fevereiro, 2016 por edsonmoretti

[Rafael Dias]

Correção enviada ao SVN.

@rpassos

O ACBr é todo x86 a compilação em x64 é apenas para teste não garantimos o funcionamento da mesma.

[edsonmoretti]

Em 01/02/2016 at 16:05, rpassos disse:

Boa tarde!

Também estou enfrentando este problema da data. Baixei uma nova versão do jAcbrFramework pelo svn e fiz a atualização das classes em meu projeto. Após efetuar esta atualização ele continua com a data errada e agora esta pegando a hora como 12. Ex: Fiz uma venda hoje 01/02/2016 as 16:46 e ele salvou como 02/02/2016 as 04:16.

 

então eu também atualizei a dll ACBrFramework64.dll e ele passou a nem ativar o ACBR dando o erro:

Error looking up function 'ECF_Create': Não foi possível encontrar o procedimento especifico.

Ele esta apontando para esta linha no meu codigo

aCBrECF.setModelo(Integer.valueOf(configuracao.getImpressora().getModeloACBr())

que neste caso o modelo ACBr é 2

Isso ACBr x32

Antes eu usava o X64 porém começou a surgir alguns problemas, então como faço pra usar no windows x64?

SO x64 + JRE/JDK x86 + DLL x86

Se fizer essa alteração irá ficar com a DLL mais recente e funcionando normal. Vlw.

[rpassos]

OK, eu só utilizava a 64 em desenvolvimento. Irei passar para 32. Valeu. Vou efetuar os testes de data agora.

[rpassos]

18 minutos atrás, rpassos disse:

OK, eu só utilizava a 64 em desenvolvimento. Irei passar para 32. Valeu. Vou efetuar os testes de data agora.

Efetuado o ajuste na Hora e parece ter resolvido o problema. Vou continuar os testes. Obrigado!