나는 http://www.epochconverter.com/을 시험해 보았고 나는 100 년을 할 수 있었지만, 99 세가되면 0099가 아닌 1999 년까지 고장이 난 것 같습니다. 버그입니까? 에포크 (Epoch) 시간이 얼마나 오래 전에 나타 났는지를 나타낼 수 있어야합니다.획기적인 시간은 어느 정도까지 되돌아 갈 수 있습니까?
또한 -292275055-05-16T16 : 47 : 04.192Z를보고 한 joda-time에 MIN_LONG + 1을 연결해 보았습니다. 기본적으로 1999 년보다 좀 더 정확하고 epochconverter.com이 맞지 않는 해 -292275055를 기본적으로 사용했습니다. min을 길게 파싱합니다.
허용되는 에포크 시간의 최소값은 얼마입니까? min을 오래 사용할 수 있습니까?
감사 시스템과 같은 유닉스에 1월 1일 딘
이론 상으로는 제한이 없습니다. "획기적 시간"은 단순히 정의 된 시점 (1970 년 1 월 1 일, 자정 GMT) 전후의 초 수입니다. 충분히 넓은 숫자 유형을 사용하면 이러한 용어로 언제든지 설명 할 수 있습니다.
실제로, 같은 시간 값이 특정 한계를 넘어 의미가된다 :
A는 부호있는 32 비트 정수 늦은 1901
날짜에 부동 소수점 형식을 사용하는 경우 일부 지점을 초과하는 해상도가 손실됩니다. 시간 값에 단 정밀도 (32 비트) 부동 소수점을 사용하지 마십시오. 그들은 현재 날짜에 대해 약 2 분 (128 초)의 해상도를 가지고 있습니다! 64 비트 부동 소수점은 예측할 수있는 미래에 괜찮 았지만 모든 32 비트 정수를 정확히 나타낼 수 있기 때문에 그렇습니다.
표준 시간대는 1900 년 이전에 표준화되지 않았으므로 그 전에 시간을 나타내는 것은 정확하지 않습니다.
그레고리력은 1582 년 전에 정의되지 않았으므로 (1920 년대 말까지 보편적으로 사용되지 않았습니다!) 따라서 날짜를 기준으로 표준 날짜 변환 루틴을 사용하려고하면 잘못된 결과가 나타납니다.
마찬가지로 Annot Domini ("AD") 달력은 525 년까지 정의되지 않았습니다. 또한 연도 0이 없음을 유의하십시오.
일부 라이브러리에는 다른 임의의 제한이나 제약이있을 수 있습니다. 예를 들어 여기에 나오는 것은 Javascript 날짜 라이브러리가 1900 년에서 1999 년 사이에 100 년 미만의 기간이 속기라고 가정한다는 것입니다.
1970.
"획기적 시간"이란 말은 위키 백과에서 "Unix time"이라고하는 1970-01-01 00:00:00 UTC 이후의 초를 의미한다고 생각합니다. 32 비트 부호있는 정수를 사용하면 1901-12-13에서 2038-01-19 (GMT)까지의 날짜를 나타낼 수 있습니다 (epochconverter에서 -2^31 및 2^31-1 값을 입력하여 찾을 수 있음). 연결된 웹 사이트). Unix 시간 자체에는 최소 또는 최대 날짜 또는 정밀도가 없으며, 유일한 제한은이를 정의하는 데 사용하는 숫자입니다.
Joda-Time은 신기원 이후로 시간이 밀리 초 단위로 정의되어 있으며이를 저장하기 위해 long (64 비트 부호있는 정수)을 사용합니다. 이 기간은 -292275055 (또는 BC 292,275,055 BC)에서 +292278994 (292,278,994 AD까지)입니다.
1970 년 1 월 1 일 64 비트 시스템의 신기원 시간 전에 가면, 당신은 우주의 예상 시간보다 큰 시간이 5 배를 만들 것 언더 플로우를 얻을 것이다. 이것이 iPhone 53S에서 오류 53을 유발 한 원인입니다.
입력 연도 99를 1999 년으로 해석하는 이유는 Date.parse() 자바 스크립트 함수를 사용하여 날짜를 구문 분석 할 가능성이 높기 때문입니다. 특별한 이상.
http://www.convertunixdate.com/과 같은 다른 온라인 타임 스탬프 구문 분석기에서 올바르게 구문 분석 된 타임 스탬프를 얻을 수 있습니다. 변경되지 않았는지 확인하기 위해 연도를 4 자리 숫자로 입력해야 할 수 있습니다.