[FLOW3-general] DateTime limited to Unix timestamp?

[Jigal van Hemert]

Michael Sauter wrote:
> On 02.07.10 10:42, Jigal van Hemert wrote:
>> I see no difference:
>> - then: year stored in two decimal digits, now: seconds since "0" stored
>> in 32 binary digits
>> - then: range limited to 00-99, now: range limited to –2147483648 -
>> 2147483647
>>
>> The storage format is a bit different, but the problem is the same.
>> Timestamps beyond 2038-01-19 would be stored in large, negative numbers
>> and that would represent dates in 1901. Just like years after '99 would
>> wrap around to '00, representing 1900...
> 
> Storing a year as "07" is ambiguous right from the start, storing 
> seconds since 1970 is always the same, no matter how big the range is.
> Year 2038 is still a problem with 32-bit numbers, though. 

Both are ambiguous. For any date system you need to define the 'zero' 
moment (Epoch) and a format.

Epoch: 1-jan-1900, format: yy-mm-dd, problem: an overflow after 99-12-31 
resulting in dates like 00-01-01.

Unix timestamp: Epoch: 1-jan-1970, format: seconds in 32-bit signed 
integer, problem: an overflow after 19-jan-2038 (+2147483647) resulting 
in dates like 13-dec-1901. [1]

Hebrew calendar [2]: Epoch 7-oct-3761 BC. This means that "year 2038" 
was about 3 millenia ago.

Islamic calendar [3]: Epoch sep-622 AD. Lunar calendar with year of 
354/355 days.

Anyway, the main problem I see is that the DB storage format (4-byte 
signed integer with Unix timestamp) cannot hold the range which is 
supported by the DateTime object. The exact DB storage format is of less 
importance (although one should look for support amongst DBMSs and speed 
considerations).

[1] http://en.wikipedia.org/wiki/Year_2038_problem
[2] http://en.wikipedia.org/wiki/Hebrew_calendar
[3] http://en.wikipedia.org/wiki/Islamic_calendar
-- 
Jigal van Hemert
skype:jigal.van.hemert
msn: jigal at xs4all.nl
http://twitter.com/jigalvh