2011-11-24 36 views
22

iam trabajando con un proyecto en tiempo real donde tuve que buscar segundos desde 1970 1. He usado el siguiente código para encontrar los segundos pero estoy dando un resultado incorrecto. El código es como sigue.cómo encontrar los segundos desde 1970 en java

public long returnSeconds(int year, int month, int date) { 
    Calendar calendar1 = Calendar.getInstance(); 
    Calendar calendar2 = Calendar.getInstance(); 
    calendar1.set(1970, 01, 01); 
    calendar2.set(year, month, date); 
    long milliseconds1 = calendar1.getTimeInMillis(); 
    long milliseconds2 = calendar2.getTimeInMillis(); 
    long diff = milliseconds2 - milliseconds1; 
    long seconds = diff/1000; 
    return seconds; 
} 

En lo anterior en lugar del year,month,date estoy pasando 2011,10,1 y iam conseguir

1317510000 

pero la respuesta correcta es

1317427200 

Cualquier ayuda con respecto a esto es muy útil para mí .

+3

'getTimeInMillis()' * * medidas ya desde la época Unix (1970, etc, etc). Si miras milisegundos1, debería ser cero (a menos que tengas problemas con la zona horaria). Así que tomar la diferencia es innecesario –

Respuesta

34

Basado en su deseo de que 1317427200 sea la salida, hay varias capas de problemas para resolver.

  • Primero, como ya se ha mencionado, java ya usa una época UTC 1/1/1970. Normalmente no hay necesidad de calcular la época y realizar restas a menos que tenga reglas locales extrañas.

  • En segundo lugar, cuando crea un nuevo calendario, se inicializa a 'ahora', por lo que incluye la hora del día. Cambiar el año/mes/día no afecta los campos de la hora del día. Por lo tanto, si desea que represente la medianoche de la fecha, debe poner a cero el calendario antes de establecer la fecha.

  • En tercer lugar, no ha especificado cómo se supone que debe manejar las zonas horarias. El horario de verano puede causar diferencias en el número absoluto de segundos representados por un calendario en particular en la fecha, dependiendo de dónde se está ejecutando su JVM. Como epoch está en UTC, ¿es probable que deseemos trabajar en horario UTC? Es posible que necesite buscar aclaraciones de los creadores del sistema con el que está interactuando.

  • Cuarto, los meses en Java tienen índice cero. Enero es 0, Octubre es 9.

poner todo eso junto

Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC")); 
calendar.clear(); 
calendar.set(2011, Calendar.OCTOBER, 1); 
long secondsSinceEpoch = calendar.getTimeInMillis()/1000L; 

que le dará 1317427200

+1

mi fecha y hora es "19 sep 2062 02:30:00" y quiero obtener "-2147483648" pero no entiendo. Mi resultado actual es "2925858600". –

+1

@Varun Patel Para un número negativo uno espera que la fecha sea en 1962, no en 2062 ..... – Affe

53

Los métodos Calendar.getTimeInMillis() y Date.getTime() devuelven milisegundos desde el 1.1.1970.

para la hora actual, puede utilizar:

long seconds = System.currentTimeMillis()/1000l; 
+0

Creo que el OP quiere saber los milisegundos desde época a un tiempo específico, no necesariamente a "ahora". –

+1

¿Hay un calendario.getTimeInMillis()? Pensé que era 'Calendar.getInstance(). GetTimeInMillis()'. – eivamu

+0

¿por qué devide por 10001? – bubakazouba

7
+0

En realidad 'Date.getTime()' devuelve una cantidad de ** mili ** segundos, no segundos. Para obtener segundos, llame a 'Date.getTime()/1000'. –

3

La respuesta que desea, "1317427200", se logra si sus meses de referencia son enero y octubre. Si es así, las fechas que está buscando son 1970-ENE-01 y 2011-OCT-01, ¿correcto?

Entonces el problema son estos números que está usando para sus meses.

Consulte, si comprueba la documentación de la API de calendario o incluso las constantes proporcionadas allí ("Calendario. ENERO", "Calendario. FEBRERO" y así sucesivamente), descubrirá que los meses comienzan en 0 (en enero) .

Por lo tanto, al verificar su código, está pasando entre febrero y noviembre, lo que daría como resultado "1317510000".

Saludos cordiales.

+0

oh ... iam tratar a enero como 1 es por eso que recibí una respuesta incorrecta, de cualquier manera obtuve la respuesta. Estás en lo correcto. Gracias por la respuesta. – androiduser

4

La diferencia que se ve es más probable debido a no lo hace cero la hora, minutos, segundos y milisegundos campos de sus instancias Calendar: Calendar.getInstance() le brinda la fecha y hora actual , al igual que new Date() o System.currentTimeMillis().

Tenga en cuenta que la month field of Calendar está basado en cero, es decir, enero es 0 y no por 1.

También, hacer números no prefijo con el cero, esto puede tener un aspecto agradable y funciona incluso hasta llegar a 8: 08 no es un número válido en Java. La prefijación de números con cero hace que el compilador suponga que los está definiendo como números octales que solo funcionan hasta el 07 (para dígitos individuales).

Simplemente suelte por completo calendar1 (1970-01-01 00: 00: 00'000 es el inicio de la época, es decir, cero de todos modos) y hacer esto:

public long returnSeconds(int year, int month, int date) { 
    final Calendar cal = Calendar.getInstance(); 
    cal.set(year, month, date, 0, 0, 0); 
    cal.set(Calendar.MILLISECOND, 0); 
    return cal.getTimeInMillis()/1000; 
} 
+0

Parece la única respuesta completa al problema ... preguntándose por qué nadie lo notó. Implementación correcta, la misma firma de método solicitada. – PaoloC

1

java.time

Utilizando el marco java.time integrado en Java 8 y posterior.

import java.time.LocalDate; 
import java.time.ZoneId; 

int year = 2011; 
int month = 10; 
int day = 1; 
int date = LocalDate.of(year, month, day); 

date.atStartOfDay(ZoneId.of("UTC")).toEpochSecond; # Long = 1317427200 
8

Desde Java8:

java.time.Instant.now().getEpochSecond() 
Cuestiones relacionadas