Does anyone have a link to solution to hour of day being incorrect?
NSTimeZone tz = NSTimeZone.timeZoneWithName(Europe/London,
true);
java.util.GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(new NSTimestamp());
int year =
time zone. Europe / London is currently in BST which is 1 hour ahead
of GMT.
i think if you also print out GregorianCalendar.HOUR_OF_DAY you'll
find it's = 11, not 12, because it's using GMT.
depending on what you are trying to achieve you may find it easier to
work everything at GMT
On Jun 15, 2008, at 5:05 AM, Simon McLean wrote:
time zone. Europe / London is currently in BST which is 1 hour
ahead of GMT.
i think if you also print out GregorianCalendar.HOUR_OF_DAY you'll
find it's = 11, not 12, because it's using GMT.
depending on what you are trying to achieve
On Jan 9, 2007, at 9:22 AM, Sacha Michel Mallais wrote:
On Jan 4, 2007, at 12:49 PM, Colin Curtin wrote:
So we symbolic linked the Java directory to the native OSX one:
#!/bin/bash
# You'll want to sudo this.
cd /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/
Home/lib
mv
This solution appears to cause problems with our apps. We get this
in the WO app log when starting up:
ZoneInfo: wrong magic number: UTC
ZoneInfo:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/zi/ZoneInfoMappings
(No such file or directory)
Any ideas?
It
On Jan 10, 2007, at 12:48 PM, Colin Curtin wrote:
I hate time.
Amen, brother!
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
Heh, yes. It seems that between the various sovereign lawmakers
around the world, the Sun Java library writers and the WO library
writers, it's nearly impossible to write clear, clean time
manipulation code.
I think this is the gods' way of keeping us from building time
machines with our
On Jan 4, 2007, at 12:49 PM, Colin Curtin wrote:
We ran into this problem as well. Found a solution a few minutes ago.
OSX uses the same tz-link data that Java, Linux, Solaris, etc. uses.
So we symbolic linked the Java directory to the native OSX one:
#!/bin/bash
# You'll want to sudo this.
We ran into this problem as well. Found a solution a few minutes ago.
OSX uses the same tz-link data that Java, Linux, Solaris, etc. uses.
So we symbolic linked the Java directory to the native OSX one:
#!/bin/bash
# You'll want to sudo this.
cd
Here is the gist of the problem :
1. You need Java 1.4.2.11 or Java 1.5.0.6 to get the new zone files.
2. If you are using NSTimestamp, you need to not use it for timezone
stuff. WO still uses NSTimezone when you pass in a Java TimeZone, and
uses its own zone files, which are hopelessly out
I notice the sun tool says:
The java.vendor property value must be Sun Microsystems Inc..
so I bet it won't work for Apple JVMs. It didn't appear that Apple
had a JVM release that met the dates shown on the sun page. Maybe
we are stuck?
Thanks to all for the VERY timely replies to my
Hi everyone:
I have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we tried
to schedule an appt for March, and the NSTimestamp is giving us back
a time that is one hour earlier than the time that is designated
JVMs had adapted to the change in law.
Regards,
Jerry
On Dec 18, 2006, at 8:31 PM, Dan Faber wrote:
Hi everyone:
I have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we tried
to schedule an appt for March
, at 8:31 PM, Dan Faber wrote:
Hi everyone:
I have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we
tried to schedule an appt for March, and the NSTimestamp is giving
us back a time that is one hour earlier than the time
have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we
tried to schedule an appt for March, and the NSTimestamp is
giving us back a time that is one hour earlier than the time that
is designated. This occurs between March
everyone:
I have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we
tried to schedule an appt for March, and the NSTimestamp is
giving us back a time that is one hour earlier than the time
that is designated. This occurs
.
Java. Dates. If there is a hell on earth for developers, it is
this.
Chuck
On Dec 18, 2006, at 8:31 PM, Dan Faber wrote:
Hi everyone:
I have just run into an apparent NSTimestamp problem. I have a
scheduling program, and it has been working well. Recently we
tried to schedule
) for dates in and
out of DST. You could also store the date (at noon) in one field
and the in another.
Java. Dates. If there is a hell on earth for developers, it is this.
Chuck
On Dec 18, 2006, at 8:31 PM, Dan Faber wrote:
Hi everyone:
I have just run into an apparent NSTimestamp
On Dec 18, 2006, at 6:35 PM, Bob Stuart wrote:
I notice the sun tool says:
The java.vendor property value must be Sun Microsystems Inc..
so I bet it won't work for Apple JVMs. It didn't appear that Apple
had a JVM release that met the dates shown on the sun page. Maybe
we are stuck?
19 matches
Mail list logo
