Detecting Daylight Savings Time - last and first sundays of March & October

[Dean]

Hi...

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

I think I could solve this problem by figuring out a way of
determining the last sundays in March and October but I cant seem to
figure out how to implement this using java.util.Calendar.

I would appreciate any hints or help that you can provide.

Dean

 

[Jani Tiainen]

Dean kirjoitti:

Hi...

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

I think I could solve this problem by figuring out a way of
determining the last sundays in March and October but I cant seem to
figure out how to implement this using java.util.Calendar.

I would appreciate any hints or help that you can provide.

Reinvent the wheel, or use Joda-time library :
<http://joda-time.sourceforge.net/> and you really don't have to care
about DST in your calculations.

 

[Lew]

Dean kirjoitti:

Reinvent the wheel, or use Joda-time library :
<http://joda-time.sourceforge.net/> and you really don't have to care
about DST in your calculations.

Or store all times in UTC.

 

[Nigel Wade]

Hi...

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

You should not need to do this for yourself. Calendar and GregorianCalendar
handle timezones and DST correctly if your system is setup properly.

Here in the UK DST came in at 2am on 25th March (the clocks went forward). This
code creates 4 GregorianCalendars, at 10pm on the 24th, at 01:59:59 and
02:00:01 and 03:00:00 on the 25th. The difference between them shows you that
the calendars are correct:

public class TestTime {
public static void main(String[] args) {
GregorianCalendar cal1 = new GregorianCalendar(2007,2,24,22,0,0);
GregorianCalendar cal2 = new GregorianCalendar(2007,2,25,1,59,59);
GregorianCalendar cal3 = new GregorianCalendar(2007,2,25,2,0,1);
GregorianCalendar cal4 = new GregorianCalendar(2007,2,25,3,0,0);
DateFormat fmt = SimpleDateFormat.getInstance();

System.out.println(fmt.format(cal1.getTime()));
System.out.println(fmt.format(cal2.getTime()));
System.out.println(fmt.format(cal3.getTime()));
System.out.println(fmt.format(cal4.getTime()));

System.out.println((cal2.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);
System.out.println((cal3.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);
System.out.println((cal4.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);

}

}

Run this code in the a UK timezone and you should get a result of 3.9997, 3.0002
and 4.0002. So 01:59:59 is almost 4 hours after 10pm, whereas 02:00:01 is only
3 hours after 10pm and 03:00:01 is very slightly over 4 hours after i.e
immediately following 01:59:59. If you do something similar for your
timezone/DST changeover you should get similar results.

I think these time differences are what you need to calculate how long a car was
parked during the switch in DST, provided the clocks on the parking meters
record time in the correct way.

 

[Dean]

Hi...

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

You should not need to do this for yourself. Calendar and GregorianCalendar
handle timezones and DST correctly if your system is setup properly.

Here in the UK DST came in at 2am on 25th March (the clocks went forward). This
code creates 4 GregorianCalendars, at 10pm on the 24th, at 01:59:59 and
02:00:01 and 03:00:00 on the 25th. The difference between them shows you that
the calendars are correct:

public class TestTime {
public static void main(String[] args) {
GregorianCalendar cal1 = new GregorianCalendar(2007,2,24,22,0,0);
GregorianCalendar cal2 = new GregorianCalendar(2007,2,25,1,59,59);
GregorianCalendar cal3 = new GregorianCalendar(2007,2,25,2,0,1);
GregorianCalendar cal4 = new GregorianCalendar(2007,2,25,3,0,0);
DateFormat fmt = SimpleDateFormat.getInstance();

System.out.println(fmt.format(cal1.getTime()));
System.out.println(fmt.format(cal2.getTime()));
System.out.println(fmt.format(cal3.getTime()));
System.out.println(fmt.format(cal4.getTime()));

System.out.println((cal2.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);
System.out.println((cal3.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);
System.out.println((cal4.getTimeInMillis() -
cal1.getTimeInMillis())/60.0/60.0/1000.0);

}

}

Run this code in the a UK timezone and you should get a result of 3.9997, 3.0002
and 4.0002. So 01:59:59 is almost 4 hours after 10pm, whereas 02:00:01 is only
3 hours after 10pm and 03:00:01 is very slightly over 4 hours after i.e
immediately following 01:59:59. If you do something similar for your
timezone/DST changeover you should get similar results.

I think these time differences are what you need to calculate how long a car was
parked during the switch in DST, provided the clocks on the parking meters
record time in the correct way.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : (e-mail address removed)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

Im an idoit. Turns out that I messed up the coversion from
milliseconds to hours. The program works fine now with the change.

Thanks Nigel, I appreciate your help....

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected]>,

Here in the UK DST came in at 2am on 25th March (the clocks went forward).

The UK does not have DST, it has Summer Time. We have always known
that altering the clocks does not alter the duration of daylight.

Across the whole of the EU (remote territories excepted), the clocks
change at 01:00 UTC/GMT of the last Sundays of March and October.

All of Western Europe makes those changes simultaneously, except for
Iceland which does not have Summer Time.

Russia and nearby change on the same dates, I think, but at 02:00 local
winter time.

It's true that Summer Time here started at 2 a.m., but it's probably
better described as 01:00 GMT.

A system that recognises Summer Time in the British Isles should, for
the last Sunday of March, reject any time 01:??:??; and, for the last
Sunday of October, it should in respect of any time 01:??:?? ask whether
it is still Summer Time or now Winter Time.

<URL:http://www.merlyn.demon.co.uk/uksumtim.htm> refers.



SIDE NOTE: MS VBS DLL DatePart(*, "ww", ?, ?), which should give ISO
8601 Week Number as generally (i.e. non-US) used, errs for 2007-12-31.
It seems worth verifying that Java code does not do likewise.

<URL:http://www.merlyn.demon.co.uk/vb-date2.htm#WN> refers.

 

[Karl Uppiano]

Unless there have been very recent changes, Java should be able to deal with
daylight time for any locale, assuming that the locale and/or timezone is
set properly.

http://java.sun.com/developer/technicalArticles/Intl/USDST_Faq.html

 

[Nigel Wade]

In comp.lang.java.programmer message <[email protected]>,


The UK does not have DST, it has Summer Time.

I know that, but when communicating with left-pondians it's generally simpler to
explain things in terms they are comfortable and familiar with.

We have always known
that altering the clocks does not alter the duration of daylight.

Most of us do, however I would not contend that all UK citizens are aware of
this fact (the Govt. not excluded).

Across the whole of the EU (remote territories excepted), the clocks
change at 01:00 UTC/GMT of the last Sundays of March and October.

All of Western Europe makes those changes simultaneously, except for
Iceland which does not have Summer Time.

Russia and nearby change on the same dates, I think, but at 02:00 local
winter time.

It's true that Summer Time here started at 2 a.m., but it's probably
better described as 01:00 GMT.

Ah, true. In my youth it was 2am and that's what I remember because it used to
be quite relevant in those days, also being the end of licensing hours...
Looking up the history of summer time I see we (as with far too many things)
gave way to the EU in 1981.

 

[Roedy Green]

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

see http://mindprod.com/jgloss/timezone.html

 

[Karl Uppiano]

Hi...

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

I think I could solve this problem by figuring out a way of
determining the last sundays in March and October but I cant seem to
figure out how to implement this using java.util.Calendar.

I would appreciate any hints or help that you can provide.

The easiest way to handle time in Java (and in most languages) is simply to
use system time in milliseconds. It is a scalar value with no time zone or
daylight time discontinuities and no modulo arithmetic. You simply add or
subtract time1 to or from time2. Using a signed long, the system time range
is plus or minus about 292 million years from January 1, 1970, 00:00:00.00
GMT.

If you use system time in milliseconds for all of your internal timekeeping
calculations, when you convert it to or from a displayable format using
java.text.SimpleDateFormat, or java.util.Calendar, they will do the
conversion to the proper time zone and daylight time automatically as long
as the locale and the system clock are set correctly. You never even have to
think about it.

 

[Roedy Green]

Im trying to fix a program I wrote 2yrs ago that calculates the price
needed to charge guests for using parking facilities. The error occurs
when DST kicks in and ends. Basically at the start of DST I need to
add an hour to the total time cars are parked and deduct an hour at
the end of DST.

If you keep time as a long milliseconds since 1970 GST, you can simply
subtract to get intervals. It works across time zones, during DST
changes etc. without any special fiddles.

Your problem then becomes converting from human local time to the long
and back. See http://mindprod.com/jgloss/calendar.html

http://mindprod.com/jgloss/time.html

 

[Lew]

The easiest way to handle time in Java (and in most languages) is simply to
use system time in milliseconds. It is a scalar value with no time zone or
daylight time discontinuities and no modulo arithmetic. You simply add or
subtract time1 to or from time2. Using a signed long, the system time range
is plus or minus about 292 million years from January 1, 1970, 00:00:00.00
GMT.

"GMT" being key here. Keep your system in Zulu time. (N.b., UTC does not
have DST.)

 

[Twisted]

Ah, true. In my youth it was 2am and that's what I remember because it used to
be quite relevant in those days, also being the end of licensing hours...

"Licensing hours"?

Some kind of peculiar Brit thing?

 

[Lew]

"Licensing hours"?

Some kind of peculiar Brit thing?

Brit, yes, peculiar, no.

 

[Nigel Wade]

"Licensing hours"?

Some kind of peculiar Brit thing?

It is the hours during which licensed premises (those permitted to sell alcohol
for consumption on the premises) are allowed to sell alcohol.

I am pretty sure it is not peculiar to Britain...