I found another one (It is 2017-11-01 in local time for me) (org-time= "<2017-11-01>" "<today>") nil
This is also local timezone dependent. Tim made the point that these floats are not intended to be Unix timestamps and only used for comparison, but this implementation detail leaks quite heavily. Furthermore, the value returned by org-2ft for these comparisons isn't even constant. For example (org-2ft "<2017-10-10 10:00:00>") returns 1507629600.0 for me today, but in four days it will return a different value, 1507626000.0. Surprise, the offset from local time to UTC is not constant, even on the same machine in the same timezone. The most immediate impact of this is that all of Org mode's time comparison functions will be wrong when called during a local time offset change. For those of us who are lucky, this may be twice a year, but for others who are unlucky, it may be multiple times per year or month, up to the whims of the local government. This is one of the reasons I think "we're just using them for comparisons" doesn't excuse org-2ft doing its little time shift. The other reason is all of the regressions that change caused, including this current bug, and yet another is my gut instinct that this is a poor design choice from a technical perspective as a software engineer.
