[quote=alindre]ah tá, quando estiver num sistema de astronomia pode ser… rs
mas um simples cálculo de data, em java se torna um estudo científico, pra quê?
[/quote]
Realmente não tem necessidade, só pra quem relamente tem interesse ( não que eu não me interesse ) mais é radical dizer que você precisar estudar física e várias locuras pra entender como funciona data em java.
Tem gente que nem faculdade faz, nem sabe calcular peso em física e meche com date e calendar mto bem xD
Facil né? Responde esta então, em pseudocódigo p/ ficar mais fácil:
Data data = 17 de outubro de 2009, às 12:00:00 (meio-dia), Fuso Horário de São Paulo.
Data dataMais24Horas = data + 24 horas.
Qual é a data e hora por extenso de dataMais24Horas?
18 de outubro de 2009, às 12:00:00 (meio-dia)
isso que to dizendo, deveria ser simples como realmente é.
[quote=danielfigueiredoc][quote=alindre]ah tá, quando estiver num sistema de astronomia pode ser… rs
mas um simples cálculo de data, em java se torna um estudo científico, pra quê?
[/quote]
Realmente não tem necessidade, só pra quem relamente tem interesse ( não que eu não me interesse ) mais é radical dizer que você precisar estudar física e várias locuras pra entender como funciona data em java.
[/quote]
Não é preciso para entender datas em java. É preciso para entender datas.
Depois que vc entender datas, ai sim vc pode tentar entender datas em java.
[quote]
Tem gente que nem faculdade faz, nem sabe calcular peso em física e meche com date e calendar mto bem xD[/quote]
Será mesmo ? Vc sabe que tem pessoas fazendo isto:
public Date amanha(Date hoje){
Date amanha = new Date(hoje.getTime());
return amanha.setDate(amanha.getDate() + 1);
}Responda o desafio do Bruno, se é tão fácil…
[quote=alindre] 18 de outubro de 2009, às 12:00:00 (meio-dia)
isso que to dizendo, deveria ser simples como realmente é.
[/quote]
Bem, a parte complicada não é a pergunta nem a resposta, é saber se você considera a resposta certa, dependendo de um contexto:
Dia 18 de outubro de 2009 às 00:00:00 começa o horário de verão no Brasil.
Se eu te desse um trabalho para entregar até meio dia do dia 18, você teria 23 horas para realizá-lo.
Se eu te desse um trabalho para entregar em 24 horas, é capaz de eu querer o trabalho para meio dia, e você entregar até 13:00, e ambos estariam certos, cada um com a sua lógica.
Se nós tivéssemos fora do Brasil, ou lá em Manaus, não teria conversa, seria meio-dia mesmo.
[quote=Bruno Laturner][quote=alindre] 18 de outubro de 2009, às 12:00:00 (meio-dia)
isso que to dizendo, deveria ser simples como realmente é.
[/quote]
Bem, a parte complicada não é a pergunta nem a resposta, é saber se você considera a resposta certa, dependendo de um contexto:
Dia 18 de outubro de 2009 às 00:00:00 começa o horário de verão no Brasil.
Se eu te desse um trabalho para entregar até meio dia do dia 18, você teria 23 horas para realizá-lo.
Se eu te desse um trabalho para entregar em 24 horas, é capaz de eu querer o trabalho para meio dia, e você entregar até 13:00, e ambos estariam certos, cada um com a sua lógica.
Se nós tivéssemos fora do Brasil, ou lá em Manaus, não teria conversa, seria meio-dia mesmo.[/quote]]
agora entendi.
e tô pra dizer que tem muuuuitos sistemas por aí que nem levam em conta o horário de verão.
[quote=marcosalex]Por que será que o Delphi consegue, o .NET consegue e a API Joda Time do Java conseguem mas a Sun não consegue?
Se eu precisar de entender tanto simplesmente pra somar uma data, alguma coisa está errada. É a mesma coisa do Java antigamente quando eu queria fazer um simples crud. Felizmente a Sun está abrindo a cabeça, antes tarde do que nunca[/quote]
A Joda Time consegue porque eles fizeram o trabalho de casa. Eles estudaram o dominio em causa para saber as regras certas.
Estudaram a ISO para saber os padrões certos. E não tiveram pena do programador criando um bando de interfaces e implementações.
A Sun não estudou direito. Cometeram alguns erros exactamente porque não estudaram direito. Além disso quiseram colocar apenas uma classe. (Em java embarcado Calendar é bom demais porque uma API completa poderia ser overkill).
A API atual não ruim. Ela funciona. Embora com alguns bugs eventuais (que afetam menos de 1% dos programadores) e um design simplista. A Joda API e a nova API de datas tem objetivos maiores. Querem deixar os calculos mais fluidos (fluentes), com correção
de problemas de design da api original.
Mas lembre-se que - e isto sempre tem muita gente que esquece - a API java , ao contrário da .NET não é uma API de plataforma de aplicação. Portanto, ela não tem nenhuma responsabilidade em modelar dominios corretamente ou em coerencia com o uso que as aplicações farão. Ela tem responsabilidade de mediar com o OS (System.currentMilis() ) . O Java ainda lança a i18n como sua responsabilidade e é isso que não foi bem modelado. Porquê ? Porque é realmente complexo. Quem dá calendar.add() não dá valor ao que acontece por trás…
No java 7 manipular as datas vai ficar mais decente.
Ja fiz cada erro grotesco similares as perguntas do Bruno e do Sergio… e a api de Calendar nao ajuda a evita-los: os nomes dos metodos sao confusos, a soma de Date que o Sergio colocou é muito facil de se deixar levar. A joda-time ja deixa as coisas mais claras, e voce acaba tomando mais cuidado, ate pela nomenclatura de metodos, classes e interfaces!
[quote=sergiotaborda] A classe Date não está deprecated. Logo, ela deve ser usada como tiny type para tipagem forte de datas. Além disso Date deve ser considerado imutável pois são os seus métodos mutáveis que estão deprecated.
[/quote]
Só para constar, essa é uma excelente observação.