Is there a reason for that?
Because it seems that the functionality of mktime/localtime/gmtime is being reimplemented/duplicated alongside the daylight-saving tables which should be identical as provided in libc?
Isn't Calendar supporting a much wider range of years, i.e. not starting at 1970?
Even in 2017, time_t on 32-bit platforms is typically 32 bits (e.g. glibc uses "signed long"), which gives a range of 1901-2038, not "infinite range".
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Even in 2017, time_t on 32-bit platforms is typically 32 bits (e.g. glibc uses "signed long"), which gives a range of 1901-2038, not "infinite range".
Ok, true. This means that on most 64-bit platforms, the range nowadays is close to "infinite".
But, yes, it does answer my question: Calendar was created while 32-bit platforms were still dominant, and thus the builtin mktime()/localtime() etc. did not provide a large enough range.
I think 32-bit platforms are actually still dominant. It will take a little while longer for ARMv8 to fully penetrate the mobile market (which is the biggest one in number of installations...)
While true, for actual Pike installations 64bit dominate. The number of Pike mobile applications are quite low.
For Pike installations, "whatever Opera runs" is the dominant platform regardless of what it actually is. :-)
pike-devel@lists.lysator.liu.se
-
Jonas Walld�n ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg