0

I am using python 3.10.6. I have this function which takes a netcdf file and assigns dmin and dmax the minimum and maximum dates of the time index from that file's data. Whenever the dmin is below 1970 (i.e. 1969 and below), I get the following error:

xmin = datetime.utcfromtimestamp((dmin - sec0) / sec1).date() OSError:
[Errno 22] Invalid argument

Here is my code:

def get_minmax_date(data):
    dmin = data['time'].values.min()
    dmax = data['time'].values.max()

    sec0 = np.datetime64(0, 's')
    sec1 = np.timedelta64(1, 's')
    xmin = datetime.utcfromtimestamp((dmin - sec0) / sec1).date()
    xmax = datetime.utcfromtimestamp((dmax - sec0) / sec1).date() + timedelta(days=1)

    return xmin, xmax

I know it's a bug in the datetime library but Is there any workaround?

FObersteiner
  • 22,500
  • 8
  • 42
  • 72
pwnkit
  • 5
  • 1
  • 5
  • Double check what `(dmin - sec0) / sec1` and the other gives. The docs say that error is due to a `gmtime` failure if argument is too large. – Carcigenicate Mar 25 '23 at 15:20
  • ```print((dmin - sec0))``` ```print((dmax - sec0))``` Output: -946771200000000000 nanoseconds -757386000000000000 nanoseconds – pwnkit Mar 25 '23 at 16:47
  • @FObersteiner Yes I am. The solution suggests using ```.replace(tzinfo=timezone.utc)``` but where do I put this in my code? – pwnkit Mar 25 '23 at 17:04
  • @FObersteiner nah, still gives the same error – pwnkit Mar 25 '23 at 17:13
  • This is not a "bug" in datetime, it's a design flaw in Unix (long before but inherited by Linux). The definition of "timestamp" here is a Unix time_t value, which by definition is "seconds since 1/1/1970". – Tim Roberts Mar 25 '23 at 17:46
  • The "flaw" is the shortsightedness of the original Unix designers, in choosing a time format that would not work before 1970 nor after 2037. – Tim Roberts Mar 26 '23 at 17:29
  • @TimRoberts I wonder where you got that info from, and if it is still up-to-date. Please have a look at [this section on wikipedia](https://en.wikipedia.org/wiki/Unix_time#Representing_the_number). Coming back to the OP, I can reproduce the problem with negative input numbers to `utcfromtimestamp` on Windows 10 but not on Linux. So I would still argue that this is a fault of a platform implementation, not Unix time. Still, avoiding Unix time methods and using datetime / timedelta instead seems to be the best option here. – FObersteiner Mar 27 '23 at 06:51
  • I've added an [answer](https://stackoverflow.com/a/75853010/10197418) to the linked duplicate to clarify this. – FObersteiner Mar 27 '23 at 07:18
  • @FObersteiner -- I was there. The Unix `time` syscall returned seconds since 1/1/1970 as a 32-bit value and still does today. Hopefully, advance planning can help us have 1/19/2038 go as smoothly as 1/1/2000. – Tim Roberts Mar 27 '23 at 18:06

0 Answers0