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
