Re: [Factor-talk] how to calculate count of days
today gmt 2014-08-31 ymdtimestamp time- durationdays . today 2014-08-31 ymdtimestamp time- durationdays . today in Germany both printed 3+11/12 Perhaps simpler would be just converting to GMT first: today gmt 2014-08-31 ymdtimestamp time- durationdays -- 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
Re: [Factor-talk] how to calculate count of days
I think timestampymd just ignores the timezone information, and should
produce the same output (in fact I think implemented the exact same way) as
your timestampYMD.
On Thu, Sep 4, 2014 at 9:44 AM, Georg Simon georg.si...@auge.de wrote:
If I do understand the Factor code
ymdtimestamp correctly uses gmt but timestampymd uses local time.
So in Germany in summer
today dup timestampymd ymdtimestamp time- durationhours .
prints -2
Does that mean there is a bug in timestampymd ?
I my application I want to use date strings of the local time. So I am
thinking about local time versions. To get words that are not very long
I replaced ymd by YMD. timestampYMD forgets the gmt-offset and
YMDtimestamp expects a local date string and makes a timestamp with
timezone information like the words yesterday and today.
( YMDtimestamp replaces local-ymdtimestamp from yesterday )
USING:
calendar calendar.format calendar.format.macros
io.streams.string typed
;
IN: localDateString
TYPED: timestampYMD ( timestamp: timestamp -- str )
[ { - MM - DD } formatted ] with-string-writer
;
: YMDtimestamp ( str -- timestamp )
[ read-ymd 0 0 0 gmt-offset-duration timestamp ]
with-string-reader
;
Now
today gmt 2014-08-31 YMDtimestamp time- durationdays .
today 2014-08-31 YMDtimestamp time- durationdays .
today dup timestampYMD YMDtimestamp time- durationhours .
print 4 4 0 respectively which is what I wanted.
Oh, I see -- you want to compare a date in local time with a date in
GMT without considering the timezone difference.
Your solution seems okay, albeit a little complicated by trying to
undo the notion of timezones. Perhaps as you play with it a bit ,
you might have some idea of improvements to the API. We were trying
to preserve timezone information as much as possible, so for example
as you convert a YMD to a timestamp, it assumes GMT. Later, as you
use it, the timezone is included for time differences and other words.
--
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
--
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
Re: [Factor-talk] how to calculate count of days
Hmm, I think you're effectively doing today (in local time) minus today (in GMT), which is something sorta like this: today dup clone 0 hours gmt-offset time- durationhours (this should output the number of hours from GMT in your local timezone) The time- word takes timezones into account, effectively shifting them to GMT before subtracting. On Thu, Sep 4, 2014 at 10:46 AM, Georg Simon georg.si...@auge.de wrote: Yes I agree. But today dup timestampymd ymdtimestamp time- durationhours . in Germany in Summer prints -2 meaning that timestampymd and ymdtimestamp do not understand each other. My explanation is that timestampymd should not ignore the timezone information. It should evaluate the timestamp completely and produce a string with the date in Greenwich. I think this would be better because you wrote We were trying to preserve timezone information as much as possible, so for example as you convert a YMD to a timestamp, it assumes GMT. I think timestampymd just ignores the timezone information, and should produce the same output (in fact I think implemented the exact same way) as your timestampYMD. -- 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 -- 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
Re: [Factor-talk] how to calculate count of days
Georg's problem comes from the fact that ymdtimestamp 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 ymdtimestamp. 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
