Set your current timezone to Santiago Chile, which "falls forward" from a timezone of -0400 to -0300 between Oct 13, 2007 11:59:59 and Oct 14, 2007 01:00:00. So the first hour of Oct 14 doesn't exist because they jump an hour forward.
10/7/07 2:57 PM Chris Kane:
2007-10-14 00:00:00 doesn't exist, so the correct result is up to interpretation when creating a date from the tuple (2007, 10, 14, 0, 0, 0). CFAbsoluteTime 214027200.0 is 2007-10-14 01:00:00 when tz is Santiago.
After some thought, I agree with the developer: (1) the times bounding the non-existant 2007-10-14 00:00:00 are 214027199.999 [2007-10-13 23:59:59.999] and 214027200.000 [2007-10-14 01:00:00.000]; in the absence of the DST transition, 2007-10-14 00:00:00 would have been 214027200.000, and the DST transition has "re-identified" that time as 1am; and (2) a result of 214027200.000/2007-10-14 01:00:00.000 produces an answer which is closer to the non-existant time in more components.
10/7/07 3:24 PM Chris Kane:
The following ICU-only program demonstrates this:
#include <unicode/ucal.h>
#include <unicode/ustring.h>
#include <stdlib.h>
#include <stdio.h>
int main() {
UErrorCode status = U_ZERO_ERROR;
UChar uzone[] = {'A', 'm', 'e', 'r', 'i', 'c', 'a', '/', 'S', 'a', 'n', 't', 'i', 'a', 'g', 'o', 0};
UCalendar *cal = ucal_open(uzone, u_strlen(uzone), "en_US@calendar=gregorian", UCAL_TRADITIONAL, &status);
if (NULL == cal
U_FAILURE(status)) abort();
ucal_clear(cal);
ucal_set(cal, UCAL_YEAR, 2007);
ucal_set(cal, UCAL_MONTH, 10 - 1);
ucal_set(cal, UCAL_DAY_OF_MONTH, 14);
status = U_ZERO_ERROR;
UDate udate = ucal_getMillis(cal, &status);
if (U_FAILURE(status)) abort();
if (udate == 1192334400000.0) {
printf("returned udate is 2007-10-14 01:00:00\n");
} else if (udate == 1192330800000.0) {
printf("returned udate is 2007-10-13 23:00:00\n");
} else {
printf("returned udate (%f) is something else!\n", udate);
}
return 0;
}
Santiago, Chile, moves into DST at midnight on 2007-10-14, and 2007-10-13 23:59:59 is followed by 2007-10-14 01:00:00. Although the result of trying to create the non-existant 2007-10-14 00:00:00 time is somewhat ambiguous, we feel that 1192334400000.0 (2007-10-14 01:00:00) would be a better result than the current 1192330800000.0 (2007-10-13 23:00:00) in ICU 3.6.
Attachments
Change History
Download in other formats: |
