Support for 64-bit Date()

[Mistrel]

Date() is still using the old 32-bit POSIX time which will wrap around in 2038. Granted, that's still 27 years in the future, but it's still a problem that can affect calculations that deal with future time much earlier.

[KJ67]

+1

I ran into this issue during the summer when I was doing a small app for the office, simply speaking so ended all younger colleges up with very odd amount of years left.

[Demivec]

I think this is useful also. The currently Date library is limited to roughly a 68 year range of time. I would be in favor of changes to support a 64-bit Date().

[Seymour Clufley]

What would be the date limits with 64-bit?

[Mistrel]

What would be the date limits with 64-bit?

Approximately 292 billion years.

[blueznl]

I can live with that

[Little John]

This has been discussed repeatedly.

We can even now easily access a bigger range of dates than the current PB library does, see
http://www.purebasic.fr/english/viewtopic.php?t=33714

Regards, Little John

[MachineCode]

+1

[Hysteria]

I'd really like to see this too. I've been writing a little app that needs to go much further back than 1970 and far prefer native solutions to workarounds.

While on the subject, it would be great to be able to use 'setgadgettext' with a date gadget given that 'getgadgettext' is capable of reading it. That would avoid the need to use date() at all in this instance.