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 georg.si...@auge.de wrote: Am Tue, 2 Sep 2014 19:09:45 -0700 schrieb Alex Vondrak ajvond...@gmail.com: Thank you. ... That is, if it weren't for the GMT bit, you could just say `2014-08-31 ymdtimestamp ago durationdays`. In fact, that would make a nice ymdword: `: days-ago ( timestamp -- days ) ago durationdays ;` 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-ymdtimestamp ( str -- timestamp ) ymdtimestamp gmt-offset-duration gmt-offset ; : days-since ( str -- n ) today swap local-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 -- 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 jon.harpe...@gmail.com 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 `ymdtimestamp` to just use local time; right now it's defined with `date-gmt`: 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 `date`, 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
On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak ajvond...@gmail.com wrote: On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper jon.harpe...@gmail.com 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 `ymdtimestamp` to just use local time; right now it's defined with `date-gmt`: 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 `date`, 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
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-ymdtimestamp ( str -- timestamp ) ! str is -MM-DD ymdtimestamp gmt-offset-duration gmt-offset ; : days-since ( str -- n ) ! str is -MM-DD today swap local-ymdtimestamp time- durationdays ; The name local-ymdtimestamp warns that changing timezone is dangerous. The word days-since gives an example where local-ymdtimestamp 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 3:34 AM, Jon Harper jon.harpe...@gmail.com wrote: On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak ajvond...@gmail.com wrote: On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper jon.harpe...@gmail.com 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 `date` 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 `ymdtimestamp` `timestampymd` 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
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 ajvond...@gmail.com wrote: On Fri, Sep 5, 2014 at 3:34 AM, Jon Harper jon.harpe...@gmail.com wrote: On Fri, Sep 5, 2014 at 9:52 AM, Alex Vondrak ajvond...@gmail.com wrote: On Thu, Sep 4, 2014 at 4:06 PM, Jon Harper jon.harpe...@gmail.com 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 `date` 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 `ymdtimestamp` `timestampymd` 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 6:19 PM, Alex Vondrak ajvond...@gmail.com 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 `ymdtimestamp` `timestampymd` not being inverses of each other (without intervening GMT conversion), though. Well, changing `ymdtimestamp` 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 `timestamprfc3339` and `rfc3339timestamp` 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
