1

Google 애플리케이션 엔진에서 작업 중입니다. 그리고 클라이언트에서 보낸 시간과 서버에서 보낸 시간 사이의 시간차가 15 초 미만이면 무언가를하도록 요구하는 작업을하고 있습니다. 이 코드는 테스트 서버 (내 컴퓨터)에서 시도 할 때 완벽하게 작동합니다. 그러나 코드가 app-engine에 배포 될 때 실패합니다. 아마도 서버의 시간대가 다르면 추가/삭제 시점이 몇 시간 남았을 수 있기 때문일 것입니다.Google App Engine/Java의 시간차 계산

기본적으로 클라이언트가 다른 데이터와 함께 그의 타임 스탬프를 보내도록하는 것입니다. 그리고 서버가 시간차를 계산할 필요가있을 때 클라이언트의 타임 스탬프를 빼냅니다.

시간대가 다르면 분명히 문제가 발생할 것입니다.

이 시간대 실패를 피하기위한 한 가지 해결책은 서버가 초기 요청과 후속 처리를 모두 타임 스탬프 처리하도록하는 것이지만, 내 응용 프로그램의 경우 클라이언트가 서버를 생성 할 때 바로 타이머가 시작되는 것이 중요합니다. 클라이언트에 대해 15 초가 경과하면 서버가 아무 조치도 취할 수 없습니다.

나는 클라이언트 측과 서버 측 개발자이기 때문에 내가 한 것을 보여줄 수 있습니다.

몇몇 조건이 충족 될 경우 이것이 조금 후에 데이터 저장소에 저장되고 검색되는

new Register().sendToServer(username,location,new TimeStamp(new Date().getTime())); 

샘플 클라이언트 측 전화.

서버 측 샘플 차이

Date date= new Timestamp(new Date().getTime()); 
Date d1 = (Date) timeStampList[i]; 
long timedif = Math.abs(d1.getTime() - date.getTime()); 
if(timedif <= 15000) 
    do something; 
else 
    do something else; 

그래서 기본적으로 내 질문에 어떻게 시간대 변화를 정상화 할됩니다 찾을 수?

감사

+0

이것은 시간대와는 아무런 관련이 없습니다. getTime은 1950 년 1 월 1 일 자정부터 밀리 초를 반환합니다. timedif를 출력 할 때, 당신은 무엇을 얻습니까? 30 초 또는 3 시간입니까? 단순히 시계와 서버가 15 초 이상 꺼져있는 것일 수 있습니다. –

답변

1

(02)는 절대 unix time를 사용 System.currentTimeMillis().

이 시간은 절대적입니다. 즉, 1970 년 1 월 1 일 자정 (UTC 자정) 이후의 밀리 초가 아니기 때문에 차이를 간단히 계산할 수 있습니다.

0

@Diego Basch는 시차가 30 분에서 최대 시간 인 경우 지적했듯이 클라이언트가 서버와 동일한 시간대에 있지 않기 때문에 시간대 차이를 처리해야합니다.

JavaScript의 클라이언트 시간대는 new Date().getTimezoneOffset()으로 확인할 수 있습니다. 참고 : UTC 오프셋은 분 단위로 반환됩니다.

서버에서 Calendar.getInstance().getTimeZone()으로 시간대를 확인할 수 있어야합니다.