How does GregorianCalendar take care summer/winter-time?

I think what you do would depend on what your interface to outlook looks like, or how outlook actually stores things.

UTC doesn't adjust for summer/winter.

In pure Java, a Date is just an instant in time, irrespective of TZ. You only care about TZ when parsing a String into a Date or formatting a Date into a String. A Date is just a long, and "right now" as a date has the same value for me in California as it does for you in London.

If Outlook handles dates and times the same way, and you're using an API that just takes and returns Dates, then you don't need to worry about TZ at that point. (You would still care if you're taking a string as input from a client and converting that to a Date.)

I hope I haven't just confused the issue, but it's hard to be more specific without a better understanding of what you're doing, what Outlook does, and what your interface to it looks like.

jverda at 2007-7-13 4:37:29 >

> I use TimeZones to get the offset between the

> location of the client and UTC/GMT, so for me it has

> nothing to do with SimpleDateFormat/Strings.

> Its quite likely we talk about very different things

> ;)

Yeah, I understand that. What I'm saying is that, depending on how exactly Outlook and your interface to it work, this may be unnecessary.

> It seems I have to figure out/wether how

> summer/winter-time (in europe we have a +1h offset

> somewhere starting with March till September I think)

> is handled by Outlook.

Indeed. Understanding how Outlook handles dates seems to be one necessary piece of the puzzle.

> But is there any API which does care about such

> special "time-anomalies"?

What do you mean "time anomalies"?

jverda at 2007-7-13 4:37:29 >

> I use TimeZones to get the offset between the

> location of the client and UTC/GMT

That isn't going to work. (I think I already said this in your other post on the same topic, and the fact that you are still here asking questions about it bears that out.) There isn't a fixed offset between two timezones. The offset is different at different times of the year, depending on when (and whether) DST starts and ends in the two timezones.

Generally code that tries to get a time in timezone A to represent a time that's really in timezone B by adding offsets is a bad idea, if only because in certain instances it is impossible to do.

You don't seem to have noticed that Calendar and GregorianCalendar already have a setTimeZone() method. It probably already does what your machinations are trying to do. Seems to me that creating a Calendar object containing the time you want it to contain, then calling setTimeZone("UTC") on it, might be a good starting point.

DrClapa at 2007-7-13 4:37:29 >

> You don't seem to have noticed that Calendar and

> GregorianCalendar already have a setTimeZone()

> method. It probably already does what your

> machinations are trying to do. Seems to me that

> creating a Calendar object containing the time you

> want it to contain, then calling setTimeZone("UTC")

> on it, might be a good starting point.

You're right I've completly overseen the setTimeZone method, thanks for the tip however it does not work for me :(

GregorianCalendar cal = new GregorianCalendar(TimeZone.getTimeZone("CET");

cal.set(Calendar.YEAR, year);

cal.set(Calendar.MONTH, month-1);

cal.set(Calendar.DAY_OF_MONTH, day);

cal.set(Calendar.HOUR_OF_DAY, hour);

cal.set(Calendar.MINUTE, minute);

cal.set(Calendar.SECOND, second);

cal.setTimeZone(TimeZone.getTimeZone("UTC"));

The setTimeZone-Method does nothing, the date/time is still the same as before calling it :(

Sorry for nerving with such newbish stuff and thanks a lot for your patience, lg Clemens

linuxhippya at 2007-7-13 4:37:30 >

> In fact no, nothing changes if I set a different

> timezone on GregorianCalendar, no change in HOUR,

> nowhere.

import java.util.*;

import java.text.*;

public class CalTZTest {

public static void main(String[] args) throws Exception {

Calendar cal = new GregorianCalendar();

TimeZone tz;

System.out.println("Initial date is " + cal.getTime());

System.out.println("Initial hour is " + cal.get(Calendar.HOUR));

System.out.println("Intial AM_PM is " + cal.get(Calendar.AM_PM));

System.out.println("Initial day of month is " + cal.get(Calendar.DATE));

System.out.println("Initial TZ is " + cal.getTimeZone().getDisplayName());

System.out.println();

tz = TimeZone.getTimeZone("GMT");

System.out.println("New TZ to set is: " + tz.getDisplayName());

cal.setTimeZone(tz);

System.out.println("New date is " + cal.getTime());

System.out.println("New hour is " + cal.get(Calendar.HOUR));

System.out.println("Intial AM_PM is " + cal.get(Calendar.AM_PM));

System.out.println("New day of month is " + cal.get(Calendar.DATE));

System.out.println("New TZ is " + cal.getTimeZone().getDisplayName());

System.out.println();

}

}

:; java -cp classes CalTZTest

Initial date is Sun Feb 05 16:32:08 PST 2006

Initial hour is 4

Intial AM_PM is 1

Initial day of month is 5

Initial TZ is Pacific Standard Time

New TZ to set is: Greenwich Mean Time

New date is Sun Feb 05 16:32:08 PST 2006

New hour is 0

Intial AM_PM is 0

New day of month is 6

New TZ is Greenwich Mean Time

> The only thing I would like to do would be:

> 1.) I have a time which is e.g. 23:59 in the client's

> TimeZone (be it CET or whatever)

> 2.) get the time in UTC, respect possible DST and

> other strange circumstances.

>

> The whole things seems to become even more and more

> weird :(

>

One thing we've been trying to tell you is that in Java, a date and time doesn't have a TZ.

Let's say I'm in California and you're in London. We're talking on the phone. We say, "Let's start counting time from right... NOW." It's 16:30 for me and 00:30 the next day for you.

A while later, somebody asks one of us "How much time has elapsed since you started counting?" It doesn't matter whether they ask me or you, the answer will be the same. That's what a java.util.Date is.

When you feed a Date into a Calendar, you're just telling it how much time has elapsed since we started counting. The Calendar knows when we started--it knows that it was 00:30 in your TZ--and it knows how to convert from one TZ to another.

When we change a Calendar's TZ, we're telling it, whatever instant in time you hold, upate your relevant fields from the TZ they're currently representing for that point in time, to this new TZ.

"Now" is "now" no matter what TZ you're in (relativistic issues aside).

So when you say you want to first get a time in one TZ, and then get that same time in another TZ--that is, convert the date and our numbers for that instant in time--you're not changing a date or a time. You're just changing a human representation of that. If you want to see that as a String, use SimpleDateFormat.

Date date = new Date();

DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL);

System.out.println("Formatted date before changing TZ: " + df.format(date));

df.setTimeZone(TimeZone.getTimeZone("GMT"));

System.out.println("Formatted date after changing TZ: " + df.format(date));

Formatted date before changing TZ: Sunday, February 5, 2006 4:47:17 PM PST

Formatted date after changing TZ: Monday, February 6, 2006 12:47:17 AM GMT

jverda at 2007-7-13 4:37:30 >