At 18:53 08/11/19, Yukihiro Matsumoto wrote:
>Issue #691 has been updated by Yukihiro Matsumoto.
>
>
>Akira Tanaka claimed that by this change Time#rfc2822 no longer round trip 
>in [ruby-dev:37126].
>
>% TZ=Europe/London ./ruby -rtime -e 'p 
>Time.rfc2822(Time.local(2008,12,1).rfc2822)'
>2008-12-01 00:00:00 UTC
>
>It used to go round.
>% TZ=Europe/London ruby -rtime -e 'p Time.rfc2822(Time.local(2008,12,1).rfc2822)'
>2008-12-01 00:00:00 +0000
>
>I am afraid this is bad.
>
>He also suspects "a time zone at Universal Time" to mean a local time which 
>has zero hour difference from UTC (London e.g.), not UTC itself.

I can see no other way to interpret this.

However, having looked at the Ruby Time class, I think it is
built under the assumption that the ("physical") time zone is
always known. This is okay for exact calculations, but it is
often not appropriate in business processes and the like.

As a simple example, a meeting scheduled at 15:00 on Mondays
in London doesn't usually move to 16:00 during summer time.

My understanding is that the -00:00 notation as used by RFC 2822
is used to indicate "timezone unknown". Ideally, Ruby would have
a way to represent internally that the timezone is unknown.
But I guess that would make the Time class quite a bit more
complicated. As a fallback, it should be documented that the
Ruby Time class has this limitation, and that it assumes the
local/process timezone when none is given (as e.g. with the -00:00
notation).

Regards,   Martin.

P.S.: See also http://www.w3.org/TR/timezone/ for more background.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst / it.aoyama.ac.jp