By default, my Fedora Linux installation comes with the TZ environment variable not set. When Fan queries the system for the current time zone (why is this needed for the Fan shell, by the way? Curious), Java (both JDK 6 / x86 from Sun and OpenJDK 1.6.0 / x64 from Fedora) returns GMT-05:00, which Fan is really unhappy about:

ERROR: Cannot init current timezone
sys::ParseErr: TimeZone not found: GMT-05:00
	at fan.sys.ParseErr.<init>(ParseErr.java:65)
	at fan.sys.ParseErr.make(ParseErr.java:51)
	at fan.sys.ParseErr.make(ParseErr.java:48)
	at fan.sys.ParseErr.make(ParseErr.java:21)
	at fan.sys.TimeZone.fromStr(TimeZone.java:83)
	at fan.sys.TimeZone.fromStr(TimeZone.java:48)
	at fan.sys.TimeZone.<clinit>(TimeZone.java:519)
	at fan.sys.DateTime.<clinit>(DateTime.java:867)
	at fan.sys.Sys.<clinit>(Sys.java:490)
	at fan.sys.Pod.readFPod(Pod.java:133)
	at fan.sys.Pod.find(Pod.java:61)
	at fan.sys.Type.find(Type.java:54)
	at fanx.util.TypeParser.load(TypeParser.java:56)
	at fan.sys.Type.find(Type.java:51)
	at fanx.tools.Fan.executeType(Fan.java:109)
	at fanx.tools.Fan.execute(Fan.java:40)
	at fanx.tools.Fansh.main(Fansh.java:22)

Setting TZ to America/New_York works, but should this be fixed in Fan, or in Fedora? (Apologies if this should go to the Sourceforge bugtracker instead; there is no bug filed there so I'm not sure if it's being used)

Got here from the Wide Finder project, by the way. Cool language!

-- Michel

Thanks Michel - we'll take a look. And yeah, we're only using SF for downloads, so this is the correct place to report bugs (eventually there will be formal bug tracking on this site).

Yeap - I noticed this problem on Solaris working on WideFinder. I try to map the Java's timezone to an Olsen timezone on startup. On Windows and OS X this seems to work really well. On Unix it seems every variant does things a bit different - which is weird because one would think Unix would always use a clean Olsen tz. I've already added a fix in the code to deal with "GMT0" and "GMT+/-hh:mm". Please let me know if someone is using a variant of Linux that does something else.

But I still think there is a problem in either the OS or the JDK: GMT-5:00 is not the same as America/New_York since it doesn't come with any historical or daylight saving rules. So as a backup you can always set the timezone explicitly in "lib/sys.props".

Stephen is a Java time guru, so maybe he knows more.

GMT-5 is definitely not EST/EDT -- and even EST/EDT is not unambiguous across different countries.

So it looks like both Linux and Solaris no longer set the TZ environment variable; the common factor seems to be the Java runtime. Looking at it using Scala reveals the oddity: Java is definitely not returning the correct time zone!

scala> import java.util._
import java.util._

scala> val tz = TimeZone.getDefault()
tz: java.util.TimeZone = sun.util.calendar.ZoneInfo[id="GMT-05:00",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

scala> val tzNY = TimeZone.getTimeZone("America/New_York")
tzNY: java.util.TimeZone = sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDa...
scala> 

Whereas according to the Unix date tool:

$ date +%Z
EDT

Im having a similar problem on Ubuntu 8.04; Java reports the timezone as "US/Pacific" which is not in the timezones.ftz database:

System.out.println(TimeZone.getDefault());
// sun.util.calendar.ZoneInfo[id="US/Pacific",...

The Unix date tool returns PDT and my system timezone is set to "Americas/Los_Angeles" at the moment. I guess a quick fix would be to just add a "US/Pacific" timezone to the timezones.ftz database. Is there some piece of code or script that is used to generate this database?

The US/Pacific timezone is in the backward list which was deprecated in 1993 - so it definitely seems odd that all these Java ports to Linux are doing the wrong thing.

It might make more sense to have the Linux bash scripts pass in the tz from the OS and use that to map into the olsen database. I'll take a look.

In the meantime you can always "fix" via lib/sys.props:

// Default timezone to use for VM - can be either the simple name
// or the full name.  If not set explicitly, then the we will
// attempt to query the timezone from the Java or .NET runtime
fan.timezone=New_York

For those of you running Linux or Solaris I'd be interested in gathering some information.

1. What does Java report as the default timezone?

   import java.util.*;
   class TzTest {
     public static void main(String[] args) {
       System.out.println(java.util.TimeZone.getDefault().getID());
     }
   }

2. What does "/etc/localtime" symbolically link to?

   ls -l /etc/localtime

3. Does "/etc/timezone" exist and if so what does it contain?

   cat /etc/timezone

On our Linux box running fandev.org:

1. SystemV/EST5EDT
2. not a symbolic link
3. US/Eastern

1. Europe/Prague
2. The initial installation (Ubuntu 8.10, intrepid) got it wrong. There was no symlink and for some reason the file contained Europe/Bratislava which is not in java timezone db (jdk6u10)

I fixed this by symlinking it:

lrwxrwxrwx 1 root root 35 2008-11-02 22:39 /etc/localtime -> ../usr/share/zoneinfo/Europe/Prague

1. Europe/Prague

1. What does Java report as the default timezone?

$ java TzTest
Europe/Berlin

2. What does "/etc/localtime" symbolically link to?

$ ls -l /etc/localtime
-rw-r--r-- 1 root root 842 2008-11-04 15:13 /etc/localtime

3. Does "/etc/timezone" exist and if so what does it contain?

$ cat /etc/timezone
Europe/Berlin

On Ubuntu 8.10 Intrepid:

$ java TzTest

Asia/Calcutta

$ ls -l /etc/localtime

-rw-r--r-- 1 root root 265 2008-11-01 03:50 /etc/localtime

$ cat /etc/timezone

Asia/Kolkata

There seems to be a problem with fromJava method in current mercurial tip:

TEST FAILED
sys::TestErr: Test failed: Prague != New_York
fan.sys.Test.err (Test.java:160)
fan.sys.Test.fail (Test.java:152)
fan.sys.Test.verifyEq (Test.java:80)
fan.sys.Test.verifyEq (Test.java:74)
testSys::DateTimeTest.testJava (DateTimeTest.fan:796)

no other failures in the test.

There seems to be a problem with fromJava method in current mercurial tip:

Thanks for pointing that out - that was indeed a bug uncovered by running the test suite in another timezone. I pushed a fix to mercurial.

On Fedora 10 (x86_64):

1. What does Java report as the default timezone?

scala> java.util.TimeZone.getDefault().getID() res0: java.lang.String = GMT-05:00

1. What does "/etc/localtime" symbolically link to?

Not a symlink: -rw-r--r-- 1 root root 3519 2008-10-01 13:11 /etc/localtime

1. Does "/etc/timezone" exist and if so what does it contain?

No

hi I get same error as reported in the initial posting.

My error:

ERROR: Cannot init current timezone
sys::ParseErr: TimeZone not found: GMT-05

My TZ:

$ date +%Z
EST

My os:

Ubuntu 8.04.1

My java:

java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)

"Fix"

$ vim lib/sys.props 
fan.timezone=EST

Is this the solution? It would be nice if someone could tell me what do here ...

thanks ben

I might still not have all my hacks correct. Can you send me what Java reports as its timezone:

java.util.TimeZone.getDefault().getID();

To work around it, you to put an Olsen timezone identifier into sys props (EST is not an unambiguous identifier):

fan.timezone=New_York

Linux support for timezones is really hosed up in Java - believe it or not, but this sites gets dozens of hits for people searching for linux/java timezone issues. Linux reports GMT offsets - those are not really timezones anybody uses because those don't take into account DST rules. So if you are using Linux and care about time you should set the timezone explicitly in your lib/sys.props.

I pushed another "fix" to try and handle all the various case reported here so far.

Note that the fix just maps the GMT offsets to a generic timezone which won't know about your political regions DST rules. So there is a still a fundamental problem in Java on Linux.

brian> Can you send me what Java reports as its timezone:

$ scala: java.util.TimeZone.getDefault().getID();
line0: java.lang.String = GMT-05:00

$ cat /etc/timezone 
America/New_York

brian> So if you are using Linux and care about time you should set the timezone explicitly in your lib/sys.props.

OK, that works for me

Update the timezone-aliases.props For example I have the same for Asia/Istanbul I added to the "Asia/" section with

Asia/Istanbul=Istanbul(what it called through jdk)

Update the timezone-aliases.props For example I have the same for Asia/Istanbul I added to the "Asia/" section with

Are you suggesting that we should add an alias for Asia/Istanbul? In the Olson database that is Europe/Istanbul

Yes, it should be Europe/Istanbul not Asia/Istanbul.

I think we should create a whole new one Eurosia/Istanbul ;)

What do you think Mahmut & Mengü?