Project

General

Profile

Bug #14862

Time.parse does not handle the time zone

Added by mifrill (Aleksey Strizhak) 3 months ago. Updated 3 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
[ruby-core:87557]

Description

First I would like to thank you for your work, thank you

The point is:

Time.parse("Ends from 28 Jun 2018 12:00 BST").zone

"MSK"

DateTime.parse("Ends from 28 Jun 2018 12:00 BST").zone

"+01:00"

History

#1 [ruby-core:87559] Updated by mifrill (Aleksey Strizhak) 3 months ago

I think its wrong:

(byebug) Time.parse("Ends from 28 Jun 2018 12:00 BST").utc.to_s

"2018-06-28 09:00:00 UTC"

(byebug) Date.parse("Ends from 28 Jun 2018 12:00 BST").to_time.utc.to_s

"2018-06-27 21:00:00 UTC"

(byebug) DateTime.parse("Ends from 28 Jun 2018 12:00 BST").to_time.utc.to_s

"2018-06-28 11:00:00 UTC"

#2 [ruby-core:87573] Updated by Hanmac (Hans Mackowiak) 3 months ago

Quote:

  %Z - Abbreviated time zone name or similar information.  (OS dependent)

 %Z doesn't identify the timezone. For example, “CST” is used at America/Chicago (-06:00), America/Havana (-05:00), Asia/Harbin (+08:00), Australia/Darwin (+09:30) and Australia/Adelaide (+10:30). Also, %Z is highly dependent on the operating system. For example, it may generate a non ASCII string on Japanese Windows. i.e. the result can be different to “JST”. So the numeric time zone offset, %z, is recommended.

thats why it seems it can't parse the BST part, i even tried strptime

#3 [ruby-core:87603] Updated by mifrill (Aleksey Strizhak) 3 months ago

@Hanmac
Yeah, we can use strptime, but we still have problem, because the results is still the same, in details:

Time.strptime("Ends from 28 Jun 2018 12:00 BST".gsub(/Ends from/, "").lstrip, "%d %b %Y %H:%M %Z").zone

"MSK"

Time.strptime("Ends from 28 Jun 2018 12:00 BST".gsub(/Ends from/, "").lstrip, "%d %b %Y %H:%M %Z").utc.to_s

"2018-06-28 09:00:00 UTC"

This is incorrect results. The correctly results of this string correctly gather only by DateTime object:

DateTime.strptime("Ends from 28 Jun 2018 12:00 BST".gsub(/Ends from/, "").lstrip, "%d %b %Y %H:%M %Z").to_time.utc.to_s

"2018-06-28 11:00:00 UTC"

Yes, perhaps they looks like are different time zones, and because of this we got this behavior.

Different time zone with common abbr:

https://www.timeanddate.com/time/zones/bst
https://www.timeanddate.com/time/zones/bst-bougainville

but the problem is, the behavior is different for all three objects.

They can misunderstand the time zone, but should not the behavior be the same?

Thank you for your time.

#4 [ruby-core:87629] Updated by Hanmac (Hans Mackowiak) 3 months ago

Like i said, TimeZone is heavly OS depend and even DateTime.strptime might not return useful result!

you probably should not depend on that timezone value

like when turning a DateTime into a Time Object, the Zone does return nil for me

#5 [ruby-core:87744] Updated by nobu (Nobuyoshi Nakada) 3 months ago

mifrill (Aleksey Strizhak) wrote:

but the problem is, the behavior is different for all three objects.

Date doesn't have time zone, and Date#to_time borrows the system timezone.

They can misunderstand the time zone, but should not the behavior be the same?

Date is a discrete library, but Time is also an interface with the system time and expected to be consistent with it.
But there is no portable way to retrieve the timezone infos, except for setting the TZ environment variable before startup.

Also available in: Atom PDF