today >gmt "2014-08-31" ymd>timestamp time- duration>days .
today "2014-08-31" ymd>timestamp time- duration>days .
today in Germany both printed 3+11/12
> Perhaps simpler would be just converting to GMT first:
>
> today >gmt "2014-08-31" ymd>timestamp time- duration>days
--
If I do understand the Factor code
ymd>timestamp correctly uses gmt but timestamp>ymd uses local time.
So in Germany in summer
today dup timestamp>ymd ymd>timestamp time- duration>hours .
prints -2
Does that mean there is a bug in timestamp>ymd ?
I my application I want to use date strings of the
I think timestamp>ymd just ignores the timezone information, and should
produce the same output (in fact I think implemented the exact same way) as
your timestamp>YMD.
On Thu, Sep 4, 2014 at 9:44 AM, Georg Simon wrote:
> If I do understand the Factor code
> ymd>timestamp correctly uses gmt bu
Yes I agree.
But
today dup timestamp>ymd ymd>timestamp time- duration>hours .
in Germany in Summer prints -2
meaning that timestamp>ymd and ymd>timestamp do not understand each
other.
My explanation is that timestamp>ymd should not ignore the timezone
information. It should evaluate the timestamp
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- duration>hours
(this should output the number of hours from GMT in your local timezone)
The time- word takes timezones into accou
Georg's problem comes from the fact that "ymd>timestamp" 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 t
