I suspect that Time.parse is just not understanding the “Malay
Peninsula Standard Time” time zone. Or maybe theres something I’m just
not understanding?
It looks like Time.parse is missing the year at the end of the string,
observe:
irb(main):001:0> Time.new
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
irb(main):002:0> Time.parse “Wed Jul 19 19:47:57 Malay Peninsula
Standard Time 2006”
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
irb(main):003:0> Time.parse “Wed Jul 19 19:47:57 Malay Peninsula
Standard Time 2007”
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
irb(main):004:0> Time.parse “Wed Jul 19 19:47:57 Malay Peninsula
Standard Time 2012”
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
Does this make me the first Ruby user in Singapore? Do I get a prize?
hehe,
-Harold
On 19/07/06, Harold H. [email protected] wrote:
I suspect that Time.parse is just not understanding the “Malay
Peninsula Standard Time” time zone. Or maybe theres something I’m just
not understanding?
It looks like Time.parse is missing the year at the end of the string, observe:
irb(main):001:0> Time.new
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
That’s odd. I get
=> Wed Jul 19 13:17:16 BST 2006
Obviously, I’m not in Malaysia, but the fact that it’s an abbreviation
is significant.
irb(main):002:0> Time.parse “Wed Jul 19 19:47:57 Malay Peninsula
Standard Time 2006”
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
In fact, it doesn’t like long time zone names at all, discarding the
bit it can’t recognise and filling in the blanks:
Time.parse(“Mon Jul 19 13:17:16 BST 2004”)
=> Mon Jul 19 13:17:16 BST 2004
Time.parse(“Mon Jul 19 13:17:16 British Summer Time 2004”)
=> Wed Jul 19 13:17:16 BST 2006
Time zone names are dodgy anyway, since there are similarly-named
zones in different places (e.g. EST in Australia and North America),
but there’s still something odd going on in your case.
Paul.
On 7/19/06, Harold H. [email protected] wrote:
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
Does this make me the first Ruby user in Singapore? Do I get a prize?
hehe,
-Harold
You seem a victim of the Ruby Q., who patched negative sleep?
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
Does this make me the first Ruby user in Singapore? Do I get a prize?
hehe,
-Harold
You seem a victim of the Ruby Q., who patched negative sleep?
I actually am here from the future.
Where I come from there are no bugs in the Time class, the sleep
method accepts negative and irrational numbers, and Ruby is the
fastest language around due to its tight integration with newest
generation of cellular automata hardware. Now if you’ll excuse I’ve
got to get back.
self.sleep( -(1**0.5) )
-Harold
On 7/19/06, Harold H. [email protected] wrote:
I would say time well spent 
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
On 7/19/06, Harold H. [email protected] wrote:
irb(main):004:0> Time.parse “Wed Jul 19 19:47:57 Malay Peninsula
Standard Time 2012”
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
irb(main):006:0> Time.parse(“Wed Jul 19 19:47:57 Homer S. 2007”)
=> Wed Jul 19 19:47:57 SGT 2006
irb(main):018:0> Time.parse(“Wed Jul 19 19:47:57 SGT 2007”)
=> Thu Jul 19 19:47:57 SGT 2007
So it’s to do with the fact that you’ve got spaces in your timezone.
In any case, who the heck uses “Malay Peninsula Standard Time” anyway?
I’m pretty sure the locals don’t.
On 7/19/06, Shuying W. [email protected] wrote:
So it’s to do with the fact that you’ve got spaces in your timezone.
Not exactly - it’s even more picky than that. It looks like with
strings of the format
“Wed Jul 19 19:47:57 ANYTHING 2007”, that anything is ignored unless
it is ‘GMT’ and the current TZ is used, but the year is accepted. But
if you have more than one string between the time and the year, then
everything is ignored and it uses the current year.
irb(main):099:0> Time.parse “Thu Jul 19 18:21:38”
=> Wed Jul 19 18:21:38 Pacific Standard Time 2006
irb(main)
0> Time.parse “Wed Jul 19 18:21:38 PST 2007”
=> Thu Jul 19 19:21:38 Pacific Standard Time 2007
irb(main):101:0> Time.parse “Wed Jul 19 18:21:38 SGT 2007”
=> Thu Jul 19 18:21:38 Pacific Standard Time 2007
irb(main):102:0> Time.parse “Wed Jul 19 18:21:38 GMT 2007”
=> Thu Jul 19 18:21:38 UTC 2007
irb(main):103:0> Time.parse “Wed Jul 19 18:21:38 GMT anything 2007”
=> Wed Jul 19 18:21:38 UTC 2006
irb(main):104:0> Time.parse “Wed Jul 19 18:21:38 PST anything 2007”
=> Wed Jul 19 19:21:38 Pacific Standard Time 2006
What’s interesting is that the docs for parse suggest that a lot more
timezone names should be accepted:
http://www.ruby-doc.org/core/classes/Time.html#M000264 says
“…, this method only understands the timezone abbreviations
described in RFC 822 and the system timezone, in the order named…”
but it doesn’t even handle ‘GMT+n’
irb(main):105:0> Time.parse “Wed Jul 19 18:21:38 GMT 2007”
=> Thu Jul 19 18:21:38 UTC 2007
irb(main):106:0> Time.parse “Wed Jul 19 18:21:38 GMT+4 2007”
=> Wed Jul 19 18:21:38 UTC 2006
-Adam
“Harold H.” [email protected] writes:
irb(main):001:0> Time.new
=> Wed Jul 19 19:47:57 Malay Peninsula Standard Time 2006
Windows?
So it’s to do with the fact that you’ve got spaces in your timezone.
Not exactly - it’s even more picky than that. It looks like with
strings of the format
“Wed Jul 19 19:47:57 ANYTHING 2007”, that anything is ignored unless
it is ‘GMT’ and the current TZ is used, but the year is accepted. But
if you have more than one string between the time and the year, then
everything is ignored and it uses the current year.
fwiw, I’ve swtiched to using Time.new.to_yaml and all my problems have
gone away. Yes, even that strange itch.
Highest Regards,
-Harold
p.s. now if only we could get this helicopter to land on that whale.
“Adam S.” [email protected] writes:
So it’s to do with the fact that you’ve got spaces in your timezone.
Not exactly - it’s even more picky than that. It looks like with
strings of the format
“Wed Jul 19 19:47:57 ANYTHING 2007”, that anything is ignored unless
it is ‘GMT’ and the current TZ is used, but the year is accepted.
My local time is EDT (-4:00)
irb(main):018:0> Time.parse(“Wed Jul 19 19:47:57 2007”)
Thu Jul 19 19:47:57 EDT 2007
irb(main):019:0> Time.parse(“Wed Jul 19 19:47:57 ANYTHING 2007”)
Thu Jul 19 19:47:57 EDT 2007
To specify SGT time (+6:00):
irb(main):020:0> Time.parse(“Wed Jul 19 19:47:57 +06:00 2007”)
Thu Jul 19 09:47:57 EDT 2007
irb(main):021:0> Time.parse(“Wed Jul 19 19:47:57 +0600 2007”)
Thu Jul 19 09:47:57 EDT 2007
but it doesn’t even handle ‘GMT+n’
RFC822 does not specify GMT+n format.
"
zone = “UT” / “GMT” ; Universal Time
; North American : UT
/ “EST” / “EDT” ; Eastern: - 5/ - 4
/ “CST” / “CDT” ; Central: - 6/ - 5
/ “MST” / “MDT” ; Mountain: - 7/ - 6
/ “PST” / “PDT” ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / “-”) 4DIGIT ) ; Local differential
; hours+min. (HHMM)
"
It specifies +nnnn format.
In any case, Time.parse does not accept everything specified in
RFC822. It ignores UT and 1ALPHA (eg: 1Z for UTC and 1N for UTC+0100).
YS.
In article [email protected],
Yohanes S. [email protected] writes:
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
"
It specifies +nnnn format.
In any case, Time.parse does not accept everything specified in
RFC822. It ignores UT and 1ALPHA (eg: 1Z for UTC and 1N for UTC+0100).
1ALPHA means an ALPHA. So, Z is a zone but 1Z is not.
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 UT 2007”)’
Thu Jul 19 19:47:57 UTC 2007
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 Z 2007”)’
Thu Jul 19 19:47:57 UTC 2007
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 N 2007”)’
Fri Jul 20 05:47:57 JST 2007
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 A 2007”)’
Fri Jul 20 03:47:57 JST 2007
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 B 2007”)’
Fri Jul 20 02:47:57 JST 2007
% ruby -rtime -e ‘p Time.parse(“Wed Jul 19 19:47:57 C 2007”)’
Fri Jul 20 01:47:57 JST 2007
My localtime is JST (+0900).
Note that the comment of RFC822 has a bug: the signs of
military zones are reversed. (See RFC1123 and RFC2822)
time.rb interprets the ALPHA with fixed, RFC1123 and
RFC2822, definition.