On May 3, 2014, at 7:27, Yukihiro Matsumoto <matz / ruby.or.jp> wrote:

Matz, thanks for taking the time to deal with this.

It is much appreciated by at least some of us. :)

> According to the discussion in Japanese, formatting (output) is OK,
> but parsing is not.  For example, "Sat May 3 00:00:00 2014" can be
> parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
> because it contains contradicting information.  Hence at least some
> part of the original string should be ignored.  That wouldn't happen
> in output.  According to Tadayoshi's opinion, time_t (%s)
> fundamentally comes without timezone information from its definition,
> so that the combination is meaningless, thus ignored.

DateTime.strptime defers to the man-page for strptime for almost it's =
entire definition:

> 10004 % ri DateTime.strptime | tail -3 | head -1
> See also strptime(3) and strftime.

(from a previous email):

> Remember, in the C specification, struct tm does not have a member to
> preserve timezone (although glibc has).  Your expectation to Time and
> DateTime can only meet on some but not all platforms.

And the man-page explicitly states that resulting values are relative to =
the local time zone:

> 10009 % man 3 strptime | grep -C2 relative | head -5
>      The strptime() function parses the string in the buffer buf, =
according to
>      the string pointed to by format, and fills in the elements of the =
struc-
>      ture pointed to by tm.  The resulting values will be relative to =
the
>      local time zone.  Thus, it can be considered the reverse =
operation of
>      strftime(3).

This implies that DateTime.strptime isn't living up to it's contract, =
yes?