JRuby

Time assumes UTC timezone

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Not A Bug
  • Affects Version/s: JRuby 1.1RC3, JRuby 1.1, JRuby 1.1.1
  • Fix Version/s: None
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
  • Number of attachments :
    0

Description

Time class assumes UTC timezone.

Code below runs differently in cruby and jruby

puts Time.now

cruby correctly identifies timezone is EST, while jruby produces a UTC time.

'TZ' environment variable is not set.

Issue Links

This issue relates to:
JRUBY-3724 Jruby's "Time.now" output always outputs UTC; doesn't match MRI. Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vladimir Sizikov added a comment -

What's shell command 'date' prints?

(just trying to understand the environment).

Show
Vladimir Sizikov added a comment - What's shell command 'date' prints? (just trying to understand the environment).
Hide
Permalink
Jonathan Beyer added a comment -

'date' produces:

Tue May 20 17:54:25 EDT 2008

Show
Jonathan Beyer added a comment - 'date' produces: Tue May 20 17:54:25 EDT 2008
Hide
Permalink
Jonathan Beyer added a comment -

As an addendum to this issue, modifying the jruby startup script to set the TZ environment variable to the proper value fixes this issue.
However, I feel that it is still an issue, because jruby behaves differently on out-of-the-box installations of different Ubuntu versions (i.e. no modification to jruby script is necessary for one version, but necessary for another).

Show
Jonathan Beyer added a comment - As an addendum to this issue, modifying the jruby startup script to set the TZ environment variable to the proper value fixes this issue. However, I feel that it is still an issue, because jruby behaves differently on out-of-the-box installations of different Ubuntu versions (i.e. no modification to jruby script is necessary for one version, but necessary for another).
Hide
Permalink
Charles Oliver Nutter added a comment -

So is the problem that we don't say the ext "EDT"? On my system, Time.now looks correct:

➔ jruby -e "puts Time.now"
Thu Jul 03 15:44:12 -0500 2008
Show
Charles Oliver Nutter added a comment - So is the problem that we don't say the ext "EDT"? On my system, Time.now looks correct: 
➔ jruby -e "puts Time.now"
Thu Jul 03 15:44:12 -0500 2008
Hide
Permalink
Jonathan Beyer added a comment -

Hi Charles,

Thanks for looking into this issue.

I had an out-of-the-box Ubuntu installation. Somewhere in the Ubuntu installation process, I was asked what timezone I was in. I selected EST.
With that out-of-the-box installation, Time.now in cruby correctly uses EST. Time.now in jruby uses UTC. I don't know what method jruby (or perhaps it is at the java level) uses to deduce the proper timezone, but ideally, jruby and cruby would use the same technique.

Does that make sense?

Thanks,
Jon

Show
Jonathan Beyer added a comment - Hi Charles, Thanks for looking into this issue. I had an out-of-the-box Ubuntu installation. Somewhere in the Ubuntu installation process, I was asked what timezone I was in. I selected EST. With that out-of-the-box installation, Time.now in cruby correctly uses EST. Time.now in jruby uses UTC. I don't know what method jruby (or perhaps it is at the java level) uses to deduce the proper timezone, but ideally, jruby and cruby would use the same technique. Does that make sense? Thanks, Jon
Hide
Permalink
Vladimir Sizikov added a comment -

Johathan, Charlie,

I've been investigating this extensively today, and the picture isn't pretty.

First, the support for "short" zone names been changing over time:

a) In JDK (different versions have different rules on how to handle PDT/PST etc)
Older JDK used one approach, the newer ones use Olson database.
Also, different JDK versions have bugs related to that.

b) Olson database itself was changing over time

c) There were also Ubuntu/Debian specific bugs

So, all in all, there is a huge number of possibilities on why you, Jonathan, see this problem.

I also use Ubuntu (8.04), and I can't seem to reproduce this. For me, MRI and JRuby behave the same (I use JDK 6, but you seems to be too).

One final question. You said that installer asked you for a TimeZone and you've selected EST. I don't see such questions in Ubuntu installer. It usually asks your location and then picks the proper timezone. So, you selected your location, not the timezone, is that correct?

What's in your /etc/timezone file?

Show
Vladimir Sizikov added a comment - Johathan, Charlie, I've been investigating this extensively today, and the picture isn't pretty. First, the support for "short" zone names been changing over time: a) In JDK (different versions have different rules on how to handle PDT/PST etc) Older JDK used one approach, the newer ones use Olson database. Also, different JDK versions have bugs related to that. b) Olson database itself was changing over time c) There were also Ubuntu/Debian specific bugs So, all in all, there is a huge number of possibilities on why you, Jonathan, see this problem. I also use Ubuntu (8.04), and I can't seem to reproduce this. For me, MRI and JRuby behave the same (I use JDK 6, but you seems to be too). One final question. You said that installer asked you for a TimeZone and you've selected EST. I don't see such questions in Ubuntu installer. It usually asks your location and then picks the proper timezone. So, you selected your location, not the timezone, is that correct? What's in your /etc/timezone file?
Hide
Permalink
Jonathan Beyer added a comment -

Vladimir,

I believe you are correct in that the Ubunutu probably asked me for location, as opposed to timezone.

/etc/timezone contains America/New_York

Thanks,
Jon

Show
Jonathan Beyer added a comment - Vladimir, I believe you are correct in that the Ubunutu probably asked me for location, as opposed to timezone. /etc/timezone contains America/New_York Thanks, Jon
Hide
Permalink
Vladimir Sizikov added a comment -

Hmm, so we have almost identical systems/configs then

Jonathan, can you run the two following examples (on non-modified JRuby) :

1.

jruby -e "puts ENV['TZ']"

2.

jruby -rjava -e "puts java.lang.System.getProperty('user.timezone')"

(I'm suspecting that somehow somewhere you do have TZ or java's timezone defined and the value is one of the not-recognized ones...)

Show
Vladimir Sizikov added a comment - Hmm, so we have almost identical systems/configs then Jonathan, can you run the two following examples (on non-modified JRuby) : 1. jruby -e "puts ENV['TZ']" 2. jruby -rjava -e "puts java.lang.System.getProperty('user.timezone')" (I'm suspecting that somehow somewhere you do have TZ or java's timezone defined and the value is one of the not-recognized ones...)
Hide
Permalink
Jonathan Beyer added a comment -

Hi Vladimir,

Thanks for all of your help.

Command 1 produces 'nil'
Command 2 produces a blank string

Cheers,
Jon

Show
Jonathan Beyer added a comment - Hi Vladimir, Thanks for all of your help. Command 1 produces 'nil' Command 2 produces a blank string Cheers, Jon
Hide
Permalink
Vladimir Sizikov added a comment -

Ah, I finnally was able to figure out what's going on.

Indeed, JDK (both Sun's JDK and OpenJDK) report rather weird default timezones for US folks, and Joda Time can't handle them properly, thus defaulting to UTC.

See this message to Joda Time mailing list for the info:

http://n2.nabble.com/Major-issues-with-joda-time-on-Ubuntu-Linux-tt395643.html

Show
Vladimir Sizikov added a comment - Ah, I finnally was able to figure out what's going on. Indeed, JDK (both Sun's JDK and OpenJDK) report rather weird default timezones for US folks, and Joda Time can't handle them properly, thus defaulting to UTC. See this message to Joda Time mailing list for the info: http://n2.nabble.com/Major-issues-with-joda-time-on-Ubuntu-Linux-tt395643.html
Hide
Permalink
Vladimir Sizikov added a comment -

Some more info. It turned out that the strange behavior of JDK that reports those outdated SystemV/PST8PDT-like zones is due to bug in Ubuntu 7.10.

https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/246732

Show
Vladimir Sizikov added a comment - Some more info. It turned out that the strange behavior of JDK that reports those outdated SystemV/PST8PDT-like zones is due to bug in Ubuntu 7.10. https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/246732
Hide
Permalink
Charles Oliver Nutter added a comment -

Marking "not a bug" since it sounds like Vladimir traced this to an Ubuntu 7.10 issue.

Show
Charles Oliver Nutter added a comment - Marking "not a bug" since it sounds like Vladimir traced this to an Ubuntu 7.10 issue.

People

Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.