FW: Europe/Paris timezone bug
Jason Parks is not on the time zone list; direct replies appropriately. --ado -----Original Message----- From: Jason Parks [mailto:jason.parks@palmsource.com] Sent: Tuesday, October 28, 2003 6:17 PM To: arthur_david_olson@nih.gov Cc: Dianne Hackborn Subject: Europe/Paris timezone bug Hi, There appears to be a bug in the timezone libraries(i've tested against localtime.c 7.76) when dealing with Daylight Saving Time and the France timezone. Daylight saving goes into effect at 3:00am instead of 2:00am. Below I have attached simple test case. This is the output of the test I ran on both Mac(10.2.8) and PalmSim bash-2.05a$ TZ="Europe/Paris" ./a.out when = 0x3f9b0e44 is_dst = 1 zone = CEST Sun Oct 26 01:59:00 2003 when = 0x3f9b0e80 is_dst = 1 zone = CEST Sun Oct 26 02:00:00 2003 when = 0x3f9b11c8 is_dst = 1 zone = CEST Sun Oct 26 02:14:00 2003 when = 0x3f9b2014 is_dst = 0 zone = CET Sun Oct 26 02:15:00 2003 You will notice that the difference between 02:14:00 and 02:15:00 is 3660 which is 61 minutes. If you set the device to 2:14 and wait 46 minutes it will change the time back to 02:00. There should be no difference in setting the time to 02:00, 02:14, or 02:15 since anytime after 02:00 should fall outside of Daylight Saving Time on this date. Thanks, --jason
Jason, I am not sure I understood your problem but let me try to help you.
There appears to be a bug in the timezone libraries(i've tested against localtime.c 7.76) when dealing with Daylight Saving Time and the France timezone. Daylight saving goes into effect at 3:00am instead of 2:00am. Below I have attached simple test case.
I am not sure why do you think Daylight saving should end its effect at 2:00am localtime instead of 3:00am localtime as it's currently defined in the zoneinfo file but AFAICS, it's not a library bug, it might be a zoneinfo definition bug: Rule EU 1996 max - Oct lastSun 1:00u 0 - The above rule states that the daylight saving ends at the last sunday of october 1:00 UTC time. The Europe/Paris zone defines that Paris is one hour ahead of UTC outside daylight saving time, or 2 hours during daylight saving time so only at 3:00 local time (which is 1:00 UTC time) the daylight saving should end. Which is what is happening, isn't it? As far as as can understand, there is no library bug. There might be a zoneinfo bug if this (daylight saving ending only at 3:00am localtime) isn't what should happen. Regards, Rodrigo Severo
This is the output of the test I ran on both Mac(10.2.8) and PalmSim
bash-2.05a$ TZ="Europe/Paris" ./a.out when = 0x3f9b0e44 is_dst = 1 zone = CEST Sun Oct 26 01:59:00 2003 when = 0x3f9b0e80 is_dst = 1 zone = CEST Sun Oct 26 02:00:00 2003 when = 0x3f9b11c8 is_dst = 1 zone = CEST Sun Oct 26 02:14:00 2003 when = 0x3f9b2014 is_dst = 0 zone = CET Sun Oct 26 02:15:00 2003
You will notice that the difference between 02:14:00 and 02:15:00 is 3660 which is 61 minutes. If you set the device to 2:14 and wait 46 minutes it will change the time back to 02:00.
There should be no difference in setting the time to 02:00, 02:14, or 02:15 since anytime after 02:00 should fall outside of Daylight Saving Time on this date.
Thanks, --jason
--
---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ----------------------------------------------------
Jason, Rodrigo, and others: I at first misunderstood Jason's explanation because he wrote "...Daylight saving goes into effect..." when what he meant was "...daylight saving goes out of effect..." or "...daylight-saving time ends...", and I then didn't look at the dates in the following output. Rodrigo's explanation is correct, but it overlooks one thing: if the device's clock is set to a time between 02:00 and 03:00 on the morning that daylight saving ends, the behaviour described implies that the device regards the time it is set to as being the first occurrence of that time that night (as all times between 02:00 and 03:00 occur twice on that night). What determines that? If, as I first imagined, the time of a device is set to 02:14 on the morning daylight saving _starts_, a time that does not occur, what happens then? Alex On Friday, Oct 31, 2003, at 01:47 Australia/Sydney, Rodrigo Severo wrote:
Jason,
I am not sure I understood your problem but let me try to help you.
There appears to be a bug in the timezone libraries(i've tested against localtime.c 7.76) when dealing with Daylight Saving Time and the France timezone. Daylight saving goes into effect at 3:00am instead of 2:00am. Below I have attached simple test case.
I am not sure why do you think Daylight saving should end its effect at 2:00am localtime instead of 3:00am localtime as it's currently defined in the zoneinfo file but AFAICS, it's not a library bug, it might be a zoneinfo definition bug:
Rule EU 1996 max - Oct lastSun 1:00u 0 -
The above rule states that the daylight saving ends at the last sunday of october 1:00 UTC time.
The Europe/Paris zone defines that Paris is one hour ahead of UTC outside daylight saving time, or 2 hours during daylight saving time so only at 3:00 local time (which is 1:00 UTC time) the daylight saving should end. Which is what is happening, isn't it?
As far as as can understand, there is no library bug. There might be a zoneinfo bug if this (daylight saving ending only at 3:00am localtime) isn't what should happen.
Regards,
Rodrigo Severo
This is the output of the test I ran on both Mac(10.2.8) and PalmSim
bash-2.05a$ TZ="Europe/Paris" ./a.out when = 0x3f9b0e44 is_dst = 1 zone = CEST Sun Oct 26 01:59:00 2003 when = 0x3f9b0e80 is_dst = 1 zone = CEST Sun Oct 26 02:00:00 2003 when = 0x3f9b11c8 is_dst = 1 zone = CEST Sun Oct 26 02:14:00 2003 when = 0x3f9b2014 is_dst = 0 zone = CET Sun Oct 26 02:15:00 2003
You will notice that the difference between 02:14:00 and 02:15:00 is 3660 which is 61 minutes. If you set the device to 2:14 and wait 46 minutes it will change the time back to 02:00.
There should be no difference in setting the time to 02:00, 02:14, or 02:15 since anytime after 02:00 should fall outside of Daylight Saving Time on this date.
Thanks, --jason
--
---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ----------------------------------------------------
LIVINGSTON Alex wrote:
Jason, Rodrigo, and others:
I at first misunderstood Jason's explanation because he wrote "...Daylight saving goes into effect..." when what he meant was "...daylight saving goes out of effect..." or "...daylight-saving time ends...", and I then didn't look at the dates in the following output.
Rodrigo's explanation is correct, but it overlooks one thing: if the device's clock is set to a time between 02:00 and 03:00 on the morning that daylight saving ends, the behaviour described implies that the device regards the time it is set to as being the first occurrence of that time that night (as all times between 02:00 and 03:00 occur twice on that night). What determines that?
It all depends on how do you set the clock. If you use mktime to create a time_t, the tm_isdst member of tm is the way to indicate if you are talking about the first or the second occurence of a given time between 2:00am and 3:00am. If you are already using a timestamp, there should be no doubt at all as the timestamp, being a number of seconds since epoch leaves no doubt about which 2:14am you are talking about.
If, as I first imagined, the time of a device is set to 02:14 on the morning daylight saving _starts_, a time that does not occur, what happens then?
I have not tested it but I bet that it also depends on how you set the time. What are you using? What happened? Please report. Rodrigo Severo -- ---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ----------------------------------------------------
participants (3)
-
LIVINGSTON Alex -
Olson, Arthur David (NIH/NCI) -
Rodrigo Severo