Code Design Question - "private static final String" and Methods

[Winston Gutkowski]

Mike Simmons wrote:"America/New_York", as far as I'm concerned.

Then all I can can say is you're waaay younger than me. And just look at that name: 'New_York'? What if I get it wrong? Is it case-sensitive (I hope not)? What if I don't know how to spell 'Tallahassee' or 'Ouagadougou' or 'Des_Moines' ('_' assumed from above)?

I agree that we need good mnemonics for time zones...

But we already have them, good or otherwise; and trying to force some "semantically correct" notion on people who have already learnt to misuse them is bound to lead to trouble - kind of like java.util.Calendar's ridiculous (and lazy, I reckon) choice to make months 0-based.

I'm not trying to argue that it's wonderful, or correct; I'm simply saying that most people (certainly of my generation) equate the mnemonic 'EST' with what you would call "Eastern Time", despite the fact that we know the difference between 'Standard' and 'Daylight'. And to change the way it works from one release to another (and was it a Java release, or just a "bug" fix)? Aaagh. I wonder how many apps fell on their face as a result of that "little" change? And how many more only discovered a problem 6 months later?

Winston

[Mike Simmons]

Winston Gutkowski wrote:

Mike Simmons wrote:"America/New_York", as far as I'm concerned.

Then all I can can say is you're waaay younger than me.

Well, I'm 43 - is the gap that huge?

It might have more to do with me growing up in Arizona and having more reason to pay attention to this difference.

Winston Gutkowski wrote:And just look at that name: 'New_York'? What if I get it wrong? Is it case-sensitive (I hope not)? What if I don't know how to spell 'Tallahassee' or 'Ouagadougou' or 'Des_Moines' ('_' assumed from above)?

Maybe we're talking about different contexts here. I'm talking about what I would use, as a programmer, to request a particular time zone. Because I would look it up. And the name America/New_York comes to us from the tz database that you've been going on about. I've got a file on my system already, /usr/share/zoneinfo/America/New_York, containing the data for this zone. Other programmers seem to be able to use this data successfully. If they get it wrong, or reference a zone file that doesn't exist, then they will get an error of some sort, or get incorrect results. As you'd expect with any typo in a program or config information. As a Java programmer, I think there should be an enum somewhere that has something resembling a canonical list of these things, things that are considered guaranteed to be supported, that's readily obvious and accessible to anyone looking at the TimeZone API. So far, the closest I've found is the List of tz database time zones which seems to be de facto supported by the JDK, though I haven't seen this documented.

Now for casual use among non-programmers, fine, I know that when someone says "EST" they probably mean what is more properly called the Eastern Time Zone, or America/New_York, or EST5EDT, or even ET. And I'm not usually going to make a stink about it. Of course if they say MST and it's summertime and they're not in Arizona, I may say "do you mean MDT?" because that's actually a useful question.

Most of the time people don't really need to think about it, they just see EST or EDT appended to a time displayed somewhere, and usually it's shown correctly, because systems are usually pretty good these days at figuring out what time zone they're actually in. Sometimes though, regular users need to be able to choose for themselves what time zone they are in. And in those cases, they need to be offered a choice of good, meaningfully-labeled options. I would argue that a label like "MST" is not a good choice for this, as too many users will fail to agree on what it really means. Regardless of which group is right, there are enough people in each group that we need to make things clear for both. So in the US, I would probably offer a choice between Pacific, Mountain, Central, and Eastern, with a separate checkbox for "Use Daylight Saving Time", which is checked by default unless I have reason to believe they're in AZ. Or maybe I'd offer options for Arizona and "Mountain (excluding Arizona)". (Ignoring temporal anomalies on the Navajo reservation.)

Winston Gutkowski wrote:

I agree that we need good mnemonics for time zones...

But we already have them, good or otherwise; and trying to force some "semantically correct" notion on people who have already learnt to misuse them is bound to lead to trouble - kind of like java.util.Calendar's ridiculous (and lazy, I reckon) choice to make months 0-based.

I'm not trying to argue that it's wonderful, or correct; I'm simply saying that most people (certainly of my generation) equate the mnemonic 'EST' with what you would call "Eastern Time", despite the fact that we know the difference between 'Standard' and 'Daylight'. And to change the way it works from one release to another (and was it a Java release, or just a "bug" fix)? Aaagh. I wonder how many apps fell on their face as a result of that "little" change? And how many more only discovered a problem 6 months later?

I'm actually not sure what happened here - there were other changes in time zone info at this time, thanks to US policy changes (after Australian changes the previous year), and there were bugs reported against the JDK and elsewhere about incorrect time zones. And in this context, I remember checking the current Java release, asked for "MST", and getting a TimeZone that was returning MDT during the summer. Years later, I checked again, and I got MST in summer. And I considered that a good thing, because it's what I had asked for. I don't really know if someone fixed (IMO) the way "MST" worked, or if they were fixing a different (more subtle?) bug that had given me incorrect info the first time around.

It looks to me like MST is defined this way in the tz database, not in any JDK workaround. From the current northamerica data file:

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	US	1918	1919	-	Mar	lastSun	2:00	1:00	D
Rule	US	1918	1919	-	Oct	lastSun	2:00	0	S
Rule	US	1942	only	-	Feb	9	2:00	1:00	W # War
Rule	US	1945	only	-	Aug	14	23:00u	1:00	P # Peace
Rule	US	1945	only	-	Sep	30	2:00	0	S
Rule	US	1967	2006	-	Oct	lastSun	2:00	0	S
Rule	US	1967	1973	-	Apr	lastSun	2:00	1:00	D
Rule	US	1974	only	-	Jan	6	2:00	1:00	D
Rule	US	1975	only	-	Feb	23	2:00	1:00	D
Rule	US	1976	1986	-	Apr	lastSun	2:00	1:00	D
Rule	US	1987	2006	-	Apr	Sun>=1	2:00	1:00	D
Rule	US	2007	max	-	Mar	Sun>=8	2:00	1:00	D
Rule	US	2007	max	-	Nov	Sun>=1	2:00	0	S

# From Arthur David Olson, 2005-12-19
# We generate the files specified below to guard against old files with
# obsolete information being left in the time zone binary directory.
# We limit the list to names that have appeared in previous versions of
# this time zone package.
# We do these as separate Zones rather than as Links to avoid problems if
# a particular place changes whether it observes DST.
# We put these specifications here in the northamerica file both to
# increase the chances that they'll actually get compiled and to
# avoid the need to duplicate the US rules in another file.

# Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
Zone	EST		 -5:00	-	EST
Zone	MST		 -7:00	-	MST
Zone	HST		-10:00	-	HST
Zone	EST5EDT		 -5:00	US	E%sT
Zone	CST6CDT		 -6:00	US	C%sT
Zone	MST7MDT		 -7:00	US	M%sT
Zone	PST8PDT		 -8:00	US	P%sT

From this it looks to me like EST is defined as being GMT-5, period. While EST5EDT is defined as GMT-5, with additional modification by the "US" rules above, which govern applying DST. Or am I reading it wrong? Not sure, as this is the first time I looked at the data files this way. So apparently the tz database has been doing this since 2005 at least. I don't know what they did before that, and don't want to take additional time right now to track down historical versions of the tz database. Java, meanwhile, has had that warning in their API all along about using three-letter codes for TimeZone IDs, so I tend to figure any programmers bitten by this change (if there was one) deserve what they got.

[Winston Gutkowski]

Mike Simmons wrote:Well, I'm 43 - is the gap that huge?

I dunno. Depends on how seriously you view 12 years.

I'm actually not sure what happened here - there were other changes in time zone info at this time, thanks to US policy changes (after Australian changes the previous year), and there were bugs reported against the JDK and elsewhere about incorrect time zones. And in this context, I remember checking the current Java release, asked for "MST", and getting a TimeZone that was returning MDT during the summer. Years later, I checked again, and I got MST in summer. And I considered that a good thing, because it's what I had asked for. I don't really know if someone fixed (IMO) the way "MST" worked, or if they were fixing a different (more subtle?) bug that had given me incorrect info the first time around.

Oh well, I guess it's done; and at least as far as America timezones are concerned, its fairly consistent.

It looks to me like MST is defined this way in the tz database, not in any JDK workaround. From the current northamerica data file:

Looks similar to what I remember; although I seem to recall the 'EST' record containing a reference to EST5EDT (but it has been a while). Maybe that's what's changed.

So apparently the tz database has been doing this since 2005 at least...

And the rest. I was looking at it in 2001, and it wasn't new then.

Java, meanwhile, has had that warning in their API all along about using three-letter codes for TimeZone IDs, so I tend to figure any programmers bitten by this change (if there was one) deserve what they got.

I suppose. Seems a bit callous though, especially considering that the API isn't that swift to begin with.

Winston

[Winston Gutkowski]

Mike Simmons wrote:Maybe we're talking about different contexts here. I'm talking about what I would use, as a programmer, to request a particular time zone. Because I would look it up. And the name America/New_York comes to us from the tz database that you've been going on about...Other programmers seem to be able to use this data successfully. If they get it wrong, or reference a zone file that doesn't exist, then they will get an error of some sort, or get incorrect results. As you'd expect with any typo in a program or config information.

Actually, I'm pretty sure that the 'America/New_York' notation is a Microsoft (or possibly Linux) thing that has been retrofitted to the tz database; and in the Java API, invalid references simply return Greenwich Mean Time (???) silently, which means that theoretically every call to getTimeZone() should be accompanied by a check to make sure you got the right one.

And you're right, we are coming at this from different viewpoints. I'm an old DBA/modeller, so the problem interests me as a modeling issue. Strings (especially long ones) generally make bad database keys, since they take up space and time, and it's easy to get them wrong.

This 'America/New_York' naming also has nothing to do with timezones, it has to do with locations; so unless you want to denormalize your system entirely, you still have the issue of "naming" (or coding) a timezone, while at the same time allowing for all possible variants of DST usage; and for that I reckon some combo of current mnemonic + ISO-3166 would probably work; although I still think 'America' needs something better than 'EST5EDT' for "Eastern Time" ('ETZ' or 'ET5'?).

As far as locations are concerned, I'd be tempted to use IATA airport codes: They're reasonably well-known, they're standardized, and most people at least know their local one; and most major cities on the planet have an airport. They're also kinda cool; I know the Vancouver Tourist Board uses YVR quite extensively in its advertising.

As a Java programmer, I think there should be an enum somewhere that has something resembling a canonical list of these things...

Yup. Totally agree.

Winston

[Mike Simmons]

Winston Gutkowski wrote:Actually, I'm pretty sure that the 'America/New_York' notation is a Microsoft (or possibly Linux) thing that has been retrofitted to the tz database;

Here's Paul Eggert's proposal for time zone names from the tz mailing list, 1993. Doesn't seem to be Microsoft- or Linux-derived, unless he's just not mentioning that fact.

Winston Gutkowski wrote:and in the Java API, invalid references simply return Greenwich Mean Time (???) silently, which means that theoretically every call to getTimeZone() should be accompanied by a check to make sure you got the right one.

Very true - and very irritating. Although if you can get the IDs directly from getAvailableIDs(), then you shouldn't need to check them after that.

[Mike Simmons]

The airport code idea is an intriguing one. I would be happy to use time zone YYZ, even though I've never been to Toronto. Though I'm skeptical how far it would go - there are far more airports out there than time zones, and people might well be trying to use their obvious, well-known local airport as a time zone, even if it isn't. And many such codes would be completely unfamiliar to others not from the area.

Personally I'd like something that compactly tells us (a) base GMT offset, (b) whether or not they use DST, (c) if they use DST, are they Northern or Southern hemisphere, and (d) optional regional variants. So maybe EST/EDT could be

GMT-05N

or maybe

TZ19N

(because I'm thinking '-' signs may be less popular, so a range of 0-23 or 1-24 may work better)

Using N/S for North/South would only come into play for those who actually use DST. So Mountain Time (with DST) would be

TZ21N

And Arizona would simply be

TZ21

But then I'd also want a similar-but-different annotation on times themselves, equivalent to EST vs EDT, to say that this particular time was recorded in DST, but this other time was not, even though both were from the region TZ21N. Maybe E for Effective time? So 09:00 AM in Denver (Mountain Time) could be

09:00 TZ21E (in winter)

or

09:00TZ22E (in summer)

Hmmm, it's hard to get all the info I want into a format that is likely to catch on. And maybe Z is not a good choice, looking so close to 2 in many fonts.

[Winston Gutkowski]

Mike Simmons wrote:The airport code idea is an intriguing one. I would be happy to use time zone YYZ, even though I've never been to Toronto. Though I'm skeptical how far it would go - there are far more airports out there than time zones

Whole point. As I say 'America/New_York' or '/Louisville' or '/New_Orleans' has nothing to do with a timezone, it has to do with a location and (only by extension) the timezone and policy in place for it.

and people might well be trying to use their obvious, well-known local airport as a time zone, even if it isn't.

Only a problem if a town is on the cusp of a timezone, and the airport happens to be in the other one; although Sod's Law says that there's bound to be one.

And many such codes would be completely unfamiliar to others not from the area.

Again, possibly. But we're talking about a location→timezone translation (at least I am ). I've got no particular problem with having another one based on Area_or_Country/City_Name, even if I never use it.

Using N/S for North/South would only come into play for those who actually use DST.

Erm...why? That would assume that we've managed to get all 120-odd countries to agree about policy, let alone what we call the timezones themselves.

Personally, I think my ideal (?) code would be a 2-character timezone, not including the 'T', coupled with an ISO-3166 2-alpha, ie: something like ESUS (Eastern Standard - US). Not likely to happen anytime soon though.

Winston

[Jordan D. Williams]

Hello everyone.

As promised, I have finished the new, re-written from the ground version of my experimental project. I posted it under my "Code Review Request" thread. You can find it here.

Thanks for any and all comments.

[Winston Gutkowski]

Jordan D. Williams wrote:As promised, I have finished the new, re-written from the ground version of my experimental project. I posted it under my "Code Review Request" thread. You can find it here.

OK, I'll have a look when I can. For anyone else who's interested, here is a direct link.

Winston