View Single Post
Old 03-26-2021, 06:35 PM   #27
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 11,774
Karma: 7029857
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by ownedbycats View Post
Question: Is there a way to set an arbitrary epoch? I can see some strangeness otherwise, e.g. if to_number is used to store it to a column on *nix environment, then from_number is used on that stored number in Windows environment. Though I am not sure why someone would do this.
No. You shouldn't store the numbers. Instead store an iso-formatted date, which is guaranteed to be valid cross platform.
Quote:
Also, does the number work in negative, e.g. someone on a *nix system using to_number on a date earlier than 1970?
Maybe, as long as that is what python does. But you should banish the idea of the number being related to *nix systems. There is zero guarantee of that. The python documents say
Quote:
  • The epoch is the point where the time starts, and is platform dependent. For Unix, the epoch is January 1, 1970, 00:00:00 (UTC).
  • The term seconds since the epoch refers to the total number of elapsed seconds since the epoch, typically excluding leap seconds. Leap seconds are excluded from this total on all POSIX-compliant platforms.
  • The functions in this module may not handle dates and times before the epoch or far in the future. The cut-off point in the future is determined by the C library; for 32-bit systems, it is typically in 2038.
Quote:
Originally Posted by capink View Post
I think python implementation for this sticks with POSIX timestamp regardless of operating system (might be wrong on this). I don't have Windows to test on. But you can test the ouput of this template:

Code:
program:
	format_date('1900-01-01T00:00:00+00:00', 'to_number')
On my linux system it returns: -2208988800.0
See the above
Quote:
Originally Posted by ownedbycats View Post
I got the same result on a Windows environment. That's good that it stays the same.
I wouldn't depend on this if I were you.

My take: these numbers are good for comparing dates and doing arithmetic on dates, but not much else.
chaley is offline   Reply With Quote