Georg's problem comes from the fact that "ymd>timestamp" represents a date
by "midnight gmt", whereas "today" represents it by "midnight in the local
timezone".
The API should make it clear how we represent "dates" (ie whole days, which
are not even the same 24 hours in different time zones) with timestamp
objects.
I think "midnight gmt" is better because two objects returned by "today" on
the same date in different timezones should be equal. And this matches
"ymd>timestamp".
How about:
: today ( -- timestamp ) now midnight instant >>gmt-offset ; inline
However, the big negative impact of this representation is that comparing a
timestamp representing a date and a timestamp representing an instant
becomes meaningless (ie not all timestamps in a day are before or after a
timestamp representing a date), wherease before, it was only meaningless if
the timezone had changed (rare, but it still happens...). Since it was
already dangerous, it doesn't seem like a big deal.
Using this new convention to represent dates coherently in the whole
calendar vocab has too many implications to describe everything in one
email (changing "yesterday", "tomorow", "<date>", "monday", and many more I
guess).
If backwards compatibility is an issue, we can always create new words
instead of changing the existing ones (ie leave "today" as it is, and
create "today-date").
What do you think?
Cheers,
Jon
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
