Philip Rowlands wrote: > I'm not quite following, sorry. Absolutely agree that strings like "EST" > are present as the %Z "time zone abbreviation" in multiple timezones, > and that robust software should use numerical offsets.
Agreed. There are always ten zillion things that one wants to say about everything in a message. But if we said them all the messages would always be so long that no one would read them. So I didn't say everything that popped into my head. (Thank goodness!) But this message suffers from being fairly long because of it. > However, in the context of getdate's grammar, "EST" unambiguously means > -0500, no? It's not particularly helpful to think about strings like > "2007-07-01 EST", but it's not ambiguous to getdate. Currently, it > seems to be invalid if the current TZ has a matching string. But the case under discussion was PDT not EST. $ TZ=US/Pacific date -d"Tue Jan 14 08:25:26 PDT 2008" date: invalid date `Tue Jan 14 08:25:26 PDT 2008' At this point I don't know if PDT is ambiguous or not (you saw my comment about UTC since that would not be ambiguous so I am not biased against string timezones per se) but when things like this fail I think it is best to avoid them regardless. Even date's string timezone can be improved I think it is still better to use numeric timezone offsets. Since the problem is centered upon use of the default 'date' output I directed my comments toward highlighting that 'date -R' exists and can easily avoid the issue entirely. This was probably off in the weeds because the underlying problem was that the date presented was an invalid date. $ zdump -v US/Pacific | grep 2008 US/Pacific Sun Mar 9 09:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 PST isdst=0 gmtoff=-28800 US/Pacific Sun Mar 9 10:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 PDT isdst=1 gmtoff=-25200 US/Pacific Sun Nov 2 08:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 PDT isdst=1 gmtoff=-25200 US/Pacific Sun Nov 2 09:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 PST isdst=0 gmtoff=-28800 This shows that on my system PDT begins on Mar 9 10:00:00 2008 UTC and therefore "Tue Jan 14 08:25:26 PDT 2008" cannot be a valid time in the US. It may be a valid time elsewhere. (I should have asked how such a date string was generated in the first place given that it is an invalid string.) At that moment the timezone should be PST instead if that is in the US/Pacific timezone. > If "2007-07-01 EST" is an invalid string, then a future improved date > would need to learn the TZ mappings (EST -> US/Eastern) in order to > consistently reject it? I think the case here is that timezone strings are bound by the legislated geography of the area. Use of Daylight Saving Time is a local convention. The actual time can only be determined by consulting data tables to map local time into UTC. If the mapping fails because the indicated time does not exist then it should return the an appropriate error. Using numeric timezones bypasses the local DST convention check by moving outside of region specific geographically legislated timezones entirely. In this case it doesn't really address the issue. It simply bypasses it. Many times in practice we don't really care whether local convention uses DST or not. Using UTC or using number timezones simply avoids the issue. I am in US/Mountain (-0700) right now and of course in the summer when DST is in effect that is -0600. If I use MST or MDT that means consult the tables to find the actual offset. But if I use -0700 no table lookup is used and that conversion must work even if I use -0700 when DST is in effect or -0600 when it is not. The result of a numeric timezone error simply makes it look as if I were geographically located in a different location than I really was located but the string can still be parsed without error. But what was especially confusing was that EDT worked with TZ=US/Pacific! This is a bug in 'date'. $ TZ=US/Mountain date -d"Tue Jan 14 08:25:26 EDT 2008" Mon Jan 14 05:25:26 MST 2008 But: $ TZ=US/Eastern date -d"Tue Jan 14 08:25:26 EDT 2008" date: invalid date `Tue Jan 14 08:25:26 EDT 2008' Consulting the tables with 'zdump -v US/Eastern | grep 2008' shows that indeed "Tue Jan 14 08:25:26 EDT 2008" is not a valid date in that timezone. It should be flagged with an error regardless of local timezone setting. The invalid date string is only detected when parsed within the context of the same timezone. That is a bug. This is where Paul answered: > Paul Eggert wrote: > > The actual problem is the reverse of the original complaint. > > Coreutils should reject a usage like 'date -d "Tue Jan 14 08:25:26 EDT > > 2008" +%s', because that time stamp is invalid. Coreutils is not > > smart enough to correctly reject the time stamp now. Fixing this bug > > would take some time and is low priority. In the mean time, though, > > portable code shouldn't rely on invalid time stamps. So eventually we might see date enhanced to detect invalid timestrings regardless of the local timezone setting. > I don't see the danger in allowing all possible values from > time_zone_table for all dates, whatever the current TZ, but I suspect > I'm missing something... I may be missing something as well. And I apologize for taking a roundabout approach to answering in this reply. To gmane I should ask how such an invalid date string was created in the first place? Bob P.S. One day I plan on spending all of that saved up daylight that I get from daylight saving time. :-) _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
