CST / CDT时区更改问题

Question

We are storing time in like '22-NOV-17 05.33.51.937000000 PM' format with server default timezone CST. We have half an our time comparison in many places. So CST to CDT and CDT to CST are facing issues because on retrieval time for database we can not identify the time zone. So it is breaking our time comparison on CST to CDT and CDT to CST time changes.

We can not change our storing logic like store with timezone and store in UTC timezone because it will breaking our existing logic in many places.

So is there any way to identity date timezone like CST or CDT, stored in database with '22-NOV-17 05.33.51.937000000 PM' format.

Answer 1

We are storing time in like '22-NOV-17 05.33.51.937000000 PM' format

does not make sense with your comment

We are storing as a timestamp in database

In Oracle databases, a TIMESTAMP does not have a format - it is stored in the database as 11 bytes representing year (2 bytes), month, day, hours, minutes, seconds (1 byte each) and fractional seconds (4 bytes). It is only when whatever interface you are using (SQL/Plus, SQL Developer, Toad, Java, PHP, etc.) to talk to the database decides to show it to you, the user, that that interface will format it as a string (but the database will just keep it as bytes without any format).

Assuming you are using SQL/Plus or SQL Developer then you can find the default format using:

SELECT value FROM NLS_SESSION_PARAMETERS WHERE parameter = 'NLS_TIMESTAMP_FORMAT';

And change the default format using:

ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SSXFF9';

Or for TIMESTAMP WITH TIME ZONE

ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT = 'YYYY-MM-DD HH24:MI:SSXFF9 TZR';

So is there any way to identity date timezone like CST or CDT, stored in database with '22-NOV-17 05.33.51.937000000 PM' format.

No, without any other meta-data that could identify the source of the timestamp and indicate which location it came from (ie is there another column that links to the user who entered the data that could be mapped to a physical location and so a time zone) then it is impossible to determine which time zone it is from.

You will either need to:

• change your database column to TIMESTAMP WITH TIME ZONE and store the time zone; or
• convert all the values to the same time zone when you are storing them.

Answer 2

I am assuming by CST and CDT you mean North American Central Standard Time and Central Daylight Time such as observed in Rainy River, Chicago and Mexico (the city) among other places. More on this ambiguity later.

For 99.977 % of all times it is fairly easy to know whether they are standard time or daylight saving time. Only times from the two hours around the transition from DST to standard time are ambiguous, and as said in the comments, there is no way to know from the time stamp which is the right way to resolve this ambiguity.

java.time

This answer will take you as far into the future as possible without taking you away from Java 7. You can still use java.time , the modern Java date and time API also known as JSR-310. It has been backported to Java 6 and 7 in the ThreeTen Backport , so it's a matter of getting this and adding it to your project (just until one day you upgrade to Java 8 or later).

I am taking your word for your date-time string format. What we can do with it:

    DateTimeFormatter storedFormatter = new DateTimeFormatterBuilder()
            .parseCaseInsensitive()
            .appendPattern("d-MMM-uu hh.mm.ss.SSSSSSSSS a")
            .toFormatter(Locale.US);
    ZoneId zone = ZoneId.of("America/Mexico_City");

    String storedTime = "22-NOV-17 05.33.51.937000000 PM";
    LocalDateTime dateTime = LocalDateTime.parse(storedTime, storedFormatter);
    // First shot -- will usually be correct
    ZonedDateTime firstShot = ZonedDateTime.of(dateTime, zone);
    System.out.println(firstShot);

This prints:

2017-11-22T17:33:51.937-06:00[America/Mexico_City]

You can see that it picked an offset of -06:00, which means that the time is in standard time (CDT is -05:00).

Since your month abbreviation is in all uppercase, I needed to tell the formatter to parse case insensitively. If America/Mexico_City time zone is not appropriate for you, pick a better one, for example America/Rainy_River or America/Chicago.

Ambiguous times in fall

I once had to parse a log file containing date-times without indication of standard time and summer time (DST). Since we assumed time would always move forward, we failed at the transition to standard time, and one hour of the log file was lost. In this case we might have solved it using the information that times were in summer time until the leap backward by an hour, from there they were in standard time. You may want to think about whether something similar will be possible for you.

Other options include just taking DST time every time — this is what the above code will do — or taking an average and living with the error thus introduced.

We can at least detect the ambiguous times:

    ZoneOffset standardOffset = ZoneOffset.ofHours(-6);
    ZoneOffset dstOffset = ZoneOffset.ofHours(-5);
    // check if in fall overlap
    ZonedDateTime standardDateTime 
            = ZonedDateTime.ofLocal(dateTime, zone, standardOffset);
    ZonedDateTime dstDateTime 
            = ZonedDateTime.ofLocal(dateTime, zone, dstOffset);
    if (! standardDateTime.equals(dstDateTime)) {
        System.out.println("Ambiguous, this could be in CST or CDT: " + dateTime);
    }

Now if the string was 29-OCT-17 01.30.00.000000000 AM , I get the message

Ambiguous, this could be in CST or CDT: 2017-10-29T01:30

ZonedDateTime.ofLocal() will use the provided offset for resolving the ambiguity if it is a valid offset for the date-time and zone.

Non-existing times in the spring

Similarly we can detect if your date-time falls in the gap where the clock is moved forward in the transition to DST:

    // Check if in spring gap
    if (! firstShot.toLocalDateTime().equals(dateTime)) {
        System.out.println("Not a valid date-time, in spring gap: " + dateTime);
    }

This can give a message like

Not a valid date-time, in spring gap: 2018-04-01T02:01

I suggest you can safely reject such values. They cannot be correct.

Avoid the three letter time zone abbreviations

CST may refer to Central Standard Time (in North and Central America), Australian Central Standard Time, Cuba Standard Time and China Standard Time. CDT may mean Central Daylight Time or Cuba Daylight Time. The three and four letter abbreviations are not standardized and are very often ambiguous. Prefer time zone IDs in the region/city format, for example America/Winnipeg.