Project

General

Profile

Actions

Bug #14862

closed

Time.parse does not handle the time zone

Added by mifrill (Aleksey Strizhak) over 6 years ago. Updated almost 6 years ago.

Status:
Closed
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"

Updated by mifrill (Aleksey Strizhak) over 6 years 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"

Updated by Hanmac (Hans Mackowiak) over 6 years 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

Updated by mifrill (Aleksey Strizhak) over 6 years ago

@Hanmac (Hans Mackowiak)
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.

Updated by Hanmac (Hans Mackowiak) over 6 years 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

Updated by nobu (Nobuyoshi Nakada) over 6 years 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.

Updated by mifrill (Aleksey Strizhak) almost 6 years ago

okay, it seems like, they should not be the same. Thank you very much - we figured it out. I think we can close this one.
Thanks for your time.

Updated by duerst (Martin Dürst) almost 6 years ago

  • Status changed from Open to Closed

Closed at request of original proposer.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0