Re: [Factor-talk] how to calculate count of days
On Fri, Sep 5, 2014 at 6:19 PM, Alex Vondrak wrote: > I also realize now that this "date" vs "datetime" distinction was what Jon > was suggesting, whereas I thought he was talking about "have one version > normalize to local time, have the other normalize to GMT" (like > Date.current & Date.today in Rails). > Yes, that's indeed what I meant. Not sure if another tuple would be clearer, or if a strongly documented convention is enough.. Fair enough. I think changing timezones is less of a deal-breaker than > `ymd>timestamp` & `timestamp>ymd` not being inverses of each other (without > intervening GMT conversion), though. > Well, changing `ymd>timestamp` to assume a locale timezone makes them inverse only if the orginal timestamp was in the local timezone (ie breaks for GMT timestamp or any other timezone). The advantage would be that most of the other words in the vocab return timestamps in the local timezone so it would work most of the time. > I guess a solution to both problems could be just having more robust > parsing that could translate strings with GMT offsets. Many RFCs abound > with date formats. > We have `timestamp>rfc3339` and `rfc3339>timestamp` which support timezones. The strings look like "2014-09-05T01:00:00+02:00" 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
Re: [Factor-talk] how to calculate count of days
I also realize now that this "date" vs "datetime" distinction was what Jon was suggesting, whereas I thought he was talking about "have one version normalize to local time, have the other normalize to GMT" (like Date.current & Date.today in Rails). I'm all for a "date" vs "datetime" distinction---probably best as separate tuples. On Fri, Sep 5, 2014 at 9:06 AM, Alex Vondrak wrote: > On Fri, Sep 5, 2014 at 3:34 AM, Jon Harper wrote: > >> On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak wrote: >> >>> On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper >>> wrote: >>> How about: : today ( -- timestamp ) now midnight instant >>gmt-offset ; inline >>> >>> Or really just >>> >>> : today ( -- timestamp ) gmt midnight ; inline >>> >>> No, this is not the correct date. "2014-09-05 01:00:00+02:00" is the >> same instant as "2014-09-04 23:00:00Z" (ie "now" and "gmt" would return >> those timestamps if invoked at the same time), but the date is not the >> same: 09-05 and 09-04 (and the correct one is really 09-05 when you are in >> the +2 timezone) >> > > Ah, that makes the rest of your email suddenly make sense to me, where you > said: > > 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. >> > > I thought your idea was to normalize to GMT. I mean, why would I want to > separate the timezone from the date? Then asking for "the date of today" > would give back "it's totally 2014-09-05 locally, but I'm just going to say > that it's 2014-09-05 GMT too---even though it's actually 2014-09-04 GMT, > I'll just say that `today` is in the future". Seems more confusing to me, > since dates are intrinsically linked to timezones. I don't care if it's > normalized to GMT or to local time, so long as it's actually normalized > correctly. > > But then, I guess I'm thinking of "dates" as "datetimes" - which is how > the `calendar` vocab treats them currently (even `` just constructs a > `timestamp` tuple). I think it would be clearer if we had a separate API > for dates devoid of timestamps. In one vocab, you could call `today` and > get back "local/GMT-normalized date of today, set to the timestamp of > midnight" and in the other you would get back "local/GMT-normalized date of > today, no timestamp at all". Then dates and datetimes would be > incomparable, and adding/subtracting durations from dates would only > consider the day/month/year components (I'm thinking along the lines of how > Python works - > https://docs.python.org/2/library/datetime.html#datetime.date.day). > > >> But then things go wrong in the rare cases when you change your timezone. >> > > Fair enough. I think changing timezones is less of a deal-breaker than > `ymd>timestamp` & `timestamp>ymd` not being inverses of each other (without > intervening GMT conversion), though. > > I guess a solution to both problems could be just having more robust > parsing that could translate strings with GMT offsets. Many RFCs abound > with date formats. > -- 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
On Fri, Sep 5, 2014 at 3:34 AM, Jon Harper wrote: > On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak wrote: > >> On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper >> wrote: >> >>> How about: >>> : today ( -- timestamp ) now midnight instant >>gmt-offset ; inline >>> >> >> Or really just >> >> : today ( -- timestamp ) gmt midnight ; inline >> >> No, this is not the correct date. "2014-09-05 01:00:00+02:00" is the > same instant as "2014-09-04 23:00:00Z" (ie "now" and "gmt" would return > those timestamps if invoked at the same time), but the date is not the > same: 09-05 and 09-04 (and the correct one is really 09-05 when you are in > the +2 timezone) > Ah, that makes the rest of your email suddenly make sense to me, where you said: 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. > I thought your idea was to normalize to GMT. I mean, why would I want to separate the timezone from the date? Then asking for "the date of today" would give back "it's totally 2014-09-05 locally, but I'm just going to say that it's 2014-09-05 GMT too---even though it's actually 2014-09-04 GMT, I'll just say that `today` is in the future". Seems more confusing to me, since dates are intrinsically linked to timezones. I don't care if it's normalized to GMT or to local time, so long as it's actually normalized correctly. But then, I guess I'm thinking of "dates" as "datetimes" - which is how the `calendar` vocab treats them currently (even `` just constructs a `timestamp` tuple). I think it would be clearer if we had a separate API for dates devoid of timestamps. In one vocab, you could call `today` and get back "local/GMT-normalized date of today, set to the timestamp of midnight" and in the other you would get back "local/GMT-normalized date of today, no timestamp at all". Then dates and datetimes would be incomparable, and adding/subtracting durations from dates would only consider the day/month/year components (I'm thinking along the lines of how Python works - https://docs.python.org/2/library/datetime.html#datetime.date.day). > But then things go wrong in the rare cases when you change your timezone. > Fair enough. I think changing timezones is less of a deal-breaker than `ymd>timestamp` & `timestamp>ymd` not being inverses of each other (without intervening GMT conversion), though. I guess a solution to both problems could be just having more robust parsing that could translate strings with GMT offsets. Many RFCs abound with date formats. -- 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
> But then things go wrong in the rare cases when you change your > timezone. I have learned much and now use two new words which solve my problem: : local-ymd>timestamp ( str -- timestamp ) ! str is -MM-DD ymd>timestamp gmt-offset-duration >>gmt-offset ; : days-since ( str -- n ) ! str is -MM-DD today swap local-ymd>timestamp time- duration>days ; The name local-ymd>timestamp warns that changing timezone is dangerous. The word days-since gives an example where local-ymd>timestamp is useful. -- 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
On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak wrote: > On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper wrote: > >> How about: >> : today ( -- timestamp ) now midnight instant >>gmt-offset ; inline >> > > Or really just > > : today ( -- timestamp ) gmt midnight ; inline > > No, this is not the correct date. "2014-09-05 01:00:00+02:00" is the same instant as "2014-09-04 23:00:00Z" (ie "now" and "gmt" would return those timestamps if invoked at the same time), but the date is not the same: 09-05 and 09-04 (and the correct one is really 09-05 when you are in the +2 timezone) > I guess less drastic would be for `ymd>timestamp` to just use local time; > right now it's defined with ``: > http://docs.factorcode.org/content/word-%28ymd__gt__timestamp%29%2Ccalendar.format.html > I know John mentioned it, but I'm not sure why that shouldn't just be > ``, since most other things appear to use local time as well (per the > above). > But then things go wrong in the rare cases when you change your timezone. -- 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
On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper wrote: > How about: > : today ( -- timestamp ) now midnight instant >>gmt-offset ; inline > Or really just : today ( -- timestamp ) gmt midnight ; inline if I'm not mistaken. It's a short trip from `today`'s current definition: http://docs.factorcode.org/content/word-today,calendar.html As far as I know, that goes for the other words: their reliance is on `now` rather than `gmt` (e.g., http://docs.factorcode.org/content/word-ago%2Ccalendar.html and http://docs.factorcode.org/content/word-hence%2Ccalendar.html). I guess less drastic would be for `ymd>timestamp` to just use local time; right now it's defined with ``: http://docs.factorcode.org/content/word-%28ymd__gt__timestamp%29%2Ccalendar.format.html I know John mentioned it, but I'm not sure why that shouldn't just be ``, since most other things appear to use local time as well (per the above). > 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"). > Ah, man, we could be just like Ruby on Rails with the `Date.current` & `Date.today` distinction! :) Sorry, it's too far past my bed time to make useful contributions to the discussion, haha. That, and date & time libraries are a headache. -- 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
> > English is not my native language but could days-since be better? Just wanted to chime in here that `days-since` would be the perfect name (as in `"2014-08-21" days-since`). English is my native language and I hadn't even thought of this name! :) On Wed, Sep 3, 2014 at 1:22 AM, Georg Simon wrote: > Am Tue, 2 Sep 2014 19:09:45 -0700 > schrieb Alex Vondrak : > > Thank you. > > > ... > > > > That is, if it weren't for the GMT bit, you could just say > > `"2014-08-31" > > ymd>timestamp ago duration>days`. In fact, that would make a nice > > ymd>word: `: > > days-ago ( timestamp -- days ) ago duration>days ;` > > > But ago includes the time since midnight. So this didn't work. > > > (Not sure I would name it `days-ago`, since that's similar to `days > > ago`, which has a different meaning...but I can't think of a better > > name.) > > > English is not my native language but could days-since be better? > > > However, there's the GMT hangup. I'm not smart enough right now to > > reason about whether you could just use `ago >gmt` and get the right > > results, but I'd try it - > > http://docs.factorcode.org/content/word-__gt__gmt,calendar.html > > > Did not work: not a method for the duration class > > > Hope any of that helps or gives you some ideas. Let us know what you > > come up with! > > > Yes, important help. Now I see the cause in the information loss when > generating ymd-strings. So my code explicitly assumes that ymd-strings > give the local time: > > : local-ymd>timestamp ( str -- timestamp ) > ymd>timestamp gmt-offset-duration >>gmt-offset > ; > : days-since ( str -- n ) > today swap local-ymd>timestamp time- duration>days > ; > > > -- > 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
