Project

General

Profile

Actions

Misc #19096

closed

[Question] Time with `-00:00` offset is in UTC

Added by andrykonchin (Andrew Konchin) over 1 year ago. Updated about 1 year ago.

Status:
Closed
Assignee:
-
[ruby-core:110568]

Description

It's a bit unexpected but

Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc?
# => true

But time with +00:00 or 0 offset is treated as not UTC time:

Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false
Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false

Is it an intentional behaviour? In this case could you please clarify the reason why it works this way?


ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a)
Actions #1

Updated by andrykonchin (Andrew Konchin) over 1 year ago

  • Description updated (diff)

Updated by sawa (Tsuyoshi Sawada) over 1 year ago

On my computer, which is set to JST (+0900), the three examples make no difference:

Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => false

Updated by zverok (Victor Shepelev) over 1 year ago

On my computer (GMT+2, Europe/Kyiv timezone), the same behavior is reproducing since 3.1 (and on the current head).

[Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc?, Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc?]
# => [false, true]

Before that (2.7 and 3.0), both are false.
I'll try to debug it later this week if nobody else does.

Updated by zverok (Victor Shepelev) over 1 year ago

Oh, it is actually deliberate, see #17544:

In RFC 3339, -00:00 is used for the time in UTC is known, but the offset to local time is unknown.

Updated by andrykonchin (Andrew Konchin) over 1 year ago

Indeed. But I assumed this feature only affects #strftime's %-z directive, not treating a time zone offset.

I've checked on Ruby 3.0.3 and -00:00 wasn't treated as UTC:

Time.new(2022, 1, 1, 0, 0, 0, "-00:00").zone
# => nil
Actions #6

Updated by andrykonchin (Andrew Konchin) over 1 year ago

  • Description updated (diff)

Updated by andrykonchin (Andrew Konchin) about 1 year ago

@zverok (Victor Shepelev) Thank you for pointing at the original ticket.

TBH I was waiting so long for some official confirmation because I haven't found any mentioning that https://bugs.ruby-lang.org/issues/17544 affects not only Time#strftime method but also a way how utc offset argument (in Time construction methods) is handled. Even added tests don't check this behaviour.

Updated by nobu (Nobuyoshi Nakada) about 1 year ago

  • Status changed from Open to Closed

It is git|296a2cab.
See also the related changesets.

Updated by duerst (Martin Dürst) about 1 year ago

I'm not sure whether and how much this is relevant, but please note that the Sedate WG in the IETF has a draft (https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html, close to final) that updates RFC 3339 (https://www.rfc-editor.org/rfc/rfc3339). For details, please check https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html#name-updating-rfc-3339.

Updated by nobu (Nobuyoshi Nakada) about 1 year ago

duerst (Martin Dürst) wrote in #note-10:

I'm not sure whether and how much this is relevant, but please note that the Sedate WG in the IETF has a draft (https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html, close to final) that updates RFC 3339 (https://www.rfc-editor.org/rfc/rfc3339). For details, please check https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html#name-updating-rfc-3339.

Thank you for the interesting information.

Although that draft seems not recommending use of -00:00, but it also says

the present specification however does not formally deprecate this syntax.

at https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html#section-2-6

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like1Like0Like0Like0Like0Like0Like0Like0