JorgeStolfi
commented
10 years ago Parece que a classe Calendar do Java é pesada demais e cheia de problemas. Eu proponho usar {long int} para os timestamps internos, com mesmo significado que o unix timestamp (número de segundos desde alguma data padão). Não é bom usar milissegundos porque eles não aparecem no timestamp externo. Usar Calendar só para converter entre timestamps internos e externos. Vide http://stackoverflow.com/questions/3371326/java-date-from-unix-timestamp
Calendar mydate = Calendar.getInstance(Timezone.getTimezone("UTC"));
mydate.setTimeInMillis(timestamp*1000);
String extTimestamp =
mydate.get(Calendar.YEAR)+ "-" +
mydate.get(Calendar.MONTH) + "-" +
mydate.get(Calendar.DAY_OF_MONTH) + " " +
mydate.get(Calendar.HOUR_OF_DAY) + ":" +
mydate.get(Calendar.MINUTE) + ":" +
mydate.get(Calendar.SECOND) + " " +
"UTC"
luksfarris
Várias classes tem campos e métodos que são timestamps {data + hora}. Internamente, eles devem ser {long int}s que contam segundos desde algum instante padrão (a "época"). Há laguma classe de biblioteca Java que defina isso? {Calendar}?
Externamente (nas páginas visíveis pelo usuário) cada timestamp tem o formato "%Y-%m-%d %H:%M:%S (%Z)" onde "(%Z)" é o fuso horário (omitido se UTC). Este timestamp formatado só deve ser gerado para debugging, no ServerImp.java, e no HTMLImpl.java.