DateTime Comparison using

4,051 views
Skip to first unread message

Nick Shaw

unread,
Apr 30, 2015, 5:05:40 PM4/30/15
to robotframe...@googlegroups.com
Hello everyone,

I'm having some issues with the datetime library, specifically it seems a date used by us falls outside of the bounds of what python can handle.  Does anyone know of a workaround for this?  The error being thrown is:

OverflowError: mktime argument out of range
This is being hit when I attempt to convert the expiration date which is currently a string to a date.  The value in that field is 9999-12-31 which appears to be too much for it to handle. This could be a valid and sensible date however rather than 9999-12-31. I've done some googling and unfortunately not turning up anything useful. I'm using robot framework 2.8.7 and python 2.7.3

${CURRENT_DATE}=    Get Current Date    result_format=%Y-%m-%d
${EFFECTIVE_DATE}= Get Json Value ${GET_RESPONSE} /0/effective_date
${EXPIRATION_DATE}= Get Json Value ${GET_RESPONSE} /0/expiration_date
${EFFECTIVE_DATE}= Convert Date ${EFFECTIVE_DATE} result_format=%Y-%m-%d
${EXPIRATION_DATE}= Convert Date ${EXPIRATION_DATE} result_format=%Y-%m-%d
Should Be True '${CURRENT_DATE}'<='${EXPIRATION_DATE}'
Should Be True '${CURRENT_DATE}'>='${EFFECTIVE_DATE}'

Thanks for any help you can provide.

Nick Shaw

unread,
May 1, 2015, 4:44:55 AM5/1/15
to robotframe...@googlegroups.com
Unfortunately I was unable to find a direct solution to this and don't have time to keep at it.  However, the workaround I used was to do the comparison as strings and go from there, not ideal but gets the job done.

Tatu Aalto

unread,
May 2, 2015, 9:00:54 AM5/2/15
to robotframe...@googlegroups.com
Ugh

When one runs this:
*** Settings ***
Library           DateTime

*** Test Cases ***
Example
    ${date}=    DateTime.Convert Date
    ...    date=3028-12-31
    ...    result_format=%Y-%m-%d


one can see this:
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\robot\libraries\DateTime.py", line 354, in convert_date
    return Date(date, date_format).convert(result_format,
  File "C:\Python27\lib\site-packages\robot\libraries\DateTime.py", line 498, in __init__
    self.seconds = self._convert_date_to_seconds(date, input_format)
  File "C:\Python27\lib\site-packages\robot\libraries\DateTime.py", line 502, in _convert_date_to_seconds
    return self._string_to_epoch(date, input_format)
  File "C:\Python27\lib\site-packages\robot\libraries\DateTime.py", line 515, in _string_to_epoch
    return self._mktime_with_millis(datetime.strptime(ts, input_format))
  File "C:\Python27\lib\site-packages\robot\libraries\DateTime.py", line 549, in _mktime_with_millis
    return time.mktime(dt.timetuple()) + dt.microsecond / 10.0**6

The feature/fault lies in used time [1] library, which can not handle dates in the distant future. From the time library documentation: "The functions in this module do 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 Unix, it is typically in 2038."

You could file a bug about the issue and if you want to better date and time handling you could write your own library for it. I did, because I did need timezone support and support for wider range of in formats.

-Tatu
[1] https://docs.python.org/2/library/time.html
--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at http://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

Nick Shaw

unread,
May 12, 2015, 12:46:12 PM5/12/15
to robotframe...@googlegroups.com
Hi Tatu,

thank you for the response and providing some more light on the situation.  Luckily I don't need functionality beyond the string comparison so I can live with it without needing to create a new library.  I've a feeling I may not be so lucky next time however!

Cheers,

Nick

Reply all
Reply to author
Forward
0 new messages