问题
This is not really a technical programming question, but it has to do with dealing with and displaying time zones in Java.
In the United States, there are time zones like Eastern Time and Pacific Time, that during Daylight Savings, they are Eastern Daylight Time and Pacific Daylight Time, while when Daylight Savings is not in effect, they are Eastern Standard Time and Pacific Standard Time.
So, since Daylight Saving Time starts on the second Sunday of March, and ends on the first Sunday of November, would saying that a date between March and November is in Eastern Standard Time or Pacific Standard Time be invalid? For example, does the following date technically not exist?
Tuesday, September 29, 2015 at 10 am PST
Should it not be Pacific Daylight Time (PDT), or just simply PT to avoid having to specify Daylight or Standard?
回答1:
... would saying that a date between March and November is in Eastern Standard Time or Pacific Standard Time be invalid?
If you are talking about a time zone that doesn't observe that particular segment at that particular time, then yes - it's invalid. Eastern Standard Time is always UTC-5, and Eastern Daylight Time is always UTC-4. If you say EST when you mean UTC-4, you're using it wrong. (And people do indeed use it wrong quite often.)
However, as others pointed out, there are locations in many time zones that don't observe daylight saving time, even when the areas around them do. If you say MST in the summer, it's valid in Phoenix, but not in Los Angeles.
... or just simply PT to avoid having to specify Daylight or Standard?
Yes, you can just say PT and omit the S or the D. It's done often this way on television, but not as often with computers. Also, that doesn't hold true for time zones over the world (London uses GMT and BST - there is no common generic abbreviation there).
回答2:
Saying EST for a date/time that is in EDT, e.g. July 4th in New York, is invalid, but we humans often don't care and use EST loosely. It's wrong but we do it anyway.
In computing, we strive to be exact, so definitely invalid.
But VGR was right. Even July 4th can be in "standard" time, if you're in a locality that doesn't observe daylight savings time.
回答3:
Proper Time Zone Names
Those names such as "Pacific Daylight Time" are not true time zones. Their 3-4 letter codes are neither standardized nor unique. Do yourself a favor and forget all about them. Never use "PDT", "EST", and such in your date-time work.
For date-time work learn to use proper time zone names. These are in the format of a continent, a slash, and a city or region. These are not arbitrary or convenient, each represents a history of changes or anomalies with adjustments or definition of that time zone.
So geographical proximity is irrelevant. For example, Seattle is much farther from Los Angeles than is Phoenix. But Seattle’s official time zone is America/Los_Angeles, while Arizona uses America/Phoenix.
While most of the United States west coast uses America/Los_Angeles, not all of it does. As we said Arizona does not, nor does Metlakatla Alaska. But notice how both overlap respectively with the -07:00 and -08:00 offsets used by America/Los_Angeles in DST & standard time shifts. (See below)
So you must do your homework to learn what official time zone covers any particular location. If you don't know already in your business logic, you will have to ask the user.
Use The Framework, Luke
You should not be worrying about when Daylight Saving Time starts and ends. Use a decent framework for date-time work. Let the framework handle the nitty-gritty details about DST. Your only worry should be keeping the tz database fresh in your framework if your zones of interest have changing rules.
java.time
For Java 8 and later the framework of choice is the new built-in java.time framework. (Tutorial) Inspired by Joda-Time, defined by JSR 310, extended by the ThreeTen-Extra project.
ZoneId zoneId_Montréal = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt_Now_Montréal = ZonedDateTime.now( zoneId_Montréal );
String outputNowMontréal = zdt_Now_Montréal.toString( );
outputNowMontréal : 2015-09-04T01:39:46.962-04:00[America/Montreal]
Adjusting For DST
Daylight Saving Time (DST) is the most common anomaly in date-time work. When jumping an hour ahead or an hour behind, that means some time-of-day values do not exist at all or occur twice in a day. As the ZonedDateTime.of class doc says:
Time-zone rules, such as daylight savings, mean that not every local date-time is valid for the specified zone, thus the local date-time may be adjusted.
That method explains the rules used by java.time in making the necessary adjustments. Be sure to study them to understand the behavior.
The doc also says that rather than use the ZonedDateTime.of method, we should normally use the LocalDateTime class to create a date-time from numbers. Then apply a ZoneId to get a ZonedDateTime by using a different ZonedDateTime.of static method.
LocalDateTime localDateTime = LocalDateTime.of( 2015, 9, 29, 10, 0, 0 );
ZoneId zoneId_LosAngeles = ZoneId.of("America/Los_Angeles");
ZonedDateTime zdt_LosAngeles = ZonedDateTime.of( localDateTime, zoneId_LosAngeles ) ;
zdt_LosAngeles : 2015-09-29T10:00-07:00[America/Los_Angeles]
We can represent the very some moment in the timeline as seen in two other time zones. While America/Los_Angeles has standard & DST offsets of -08:00 & -07:00 respectively, America/Phoenix (Arizona) has only -07:00, and America/Metlakatla (Alaska) has only -08:00.
ZonedDateTime zdt_Phoenix = zdt_LosAngeles.withZoneSameInstant( ZoneId.of( "America/Phoenix" ) );
ZonedDateTime zdt_Metlakatla = zdt_LosAngeles.withZoneSameInstant( ZoneId.of("America/Metlakatla") );
zdt_Phoenix : 2015-09-29T10:00-07:00[America/Phoenix]
zdt_Metlakatla : 2015-09-29T09:00-08:00[America/Metlakatla]
The rules for adjusting for DST on “Spring Ahead” & “Fall Back” days are explained in the class doc.
The local date-time is resolved to a single instant on the time-line. This is achieved by finding a valid offset from UTC/Greenwich for the local date-time as defined by the rules of the zone ID.
In most cases, there is only one valid offset for a local date-time. In the case of an overlap, when clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".
In the case of a gap, when clocks jump forward, there is no valid offset. Instead, the local date-time is adjusted to be later by the length of the gap. For a typical one hour daylight savings change, the local date-time will be moved one hour later into the offset typically corresponding to "summer".
Joda-Time
If Java 8 technology in unavailable, use the third-party Joda-Time framework (which inspired java.time). Joda-Time works in Android, by the way, with some special builds available from others helping overcome some issue with the Dalvik classloader.
Avoid Old j.u.Date/Calendar
Avoid the old java.util.Date/.Calendar and java.text.SimpleDateFormat classes. These classes were a valiant industry-first attempt at handling date-time in a sophisticated manner. But ultimately they fail, proving to be confusing, troublesome, and flawed.
ISO 8601
Both java.time and Joda-Time offer formatters that will generate string representations of your date-time values using those 3-4 letter codes if you must have them for output. But do not use them for data storage, data exchange, or parsing.
For those purposes learn about ISO 8601 standard string formats. Both java.time and Joda-Time use ISO 8601 by default when parsing and generating string representations.
回答4:
Using SimpleDateFormat in Java, specifying either one seems to be valid. When printed, you can see that the daylight savings time conversion takes place when it's parsed, even when setLenient(false) is called.
Example:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy MMMM dd HH:mm:ss z");
sdf.setLenient(false);
Date d = sdf.parse("2015 September 29 10:00:00 PST");
System.out.println(d);
This outputs:
Tue Sep 29 11:00:00 PDT 2015
It takes PST (Pacific Standard Time) and converts it to PDT (Pacific Daylight Time) upon output. At least right now it does. At the time of this writing, daylight savings time is in effect.
PDT is accepted also:
Date d2 = sdf.parse("2015 September 29 10:00:00 PDT");
System.out.println(d2);
This outputs:
Tue Sep 29 10:00:00 PDT 2015
Note: This is likely dependent on having a United States locale. Since that is my default locale, the above works. If that isn't your locale, try adding a second parameter Locale.US to the SimpleDateFormat constructor call at the top.
来源：https://stackoverflow.com/questions/32383495/standard-time-and-daylight-time