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
> `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
