January 1997 - tz - lists.iana.org

Minute offsets
by Chris Carrier Jan. 17, 1997

Jan. 17, 1997

Markus G. Kuhn wrote: > I do not have very strong feelings about the optionality of the minute > offset, but my arguments for it are: > - only *very* few countries use it today and time zones are so often > redefined that there is some good hope that the 30-min offset zones > will disappear in 2020 or so. Then, we would not carry around > any more the obsolete minute fields in our headers. > - I personally think that the hour only offset is much more readable > and that the additional implementation effort (one single "if" in > my sample code) is so trivial that it is really not worth any > discussion. I would make minute offsets mandatory, because we are discussing not only contemporary but historical time zone data, when minute offsets were more common. Also IMHO minute offsets are not necessarily a Bad Thing; a small country without any of its territory going through an hourly meridian but with territory going through a minute offset might be better served by the minute offset zone; Portugal and Ireland, for example, fit GMT-0:30 closer than GMT or GMT-1. What I would favor is putting a colon in between hours and minutes, for readability; i.e. the time in Darwin, Australia is easier to read as GMT or UT+09:30 than as +0930. My $0.02 worth...

3 2

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Hi Ken, Hi Tom, Tom Peterson wrote: > > Since ISO C doesn't appear to present restrictions here and TOG says they > > don't support negative time_t's, perhaps this is an area where an industry > > precedent should be set. I've yet to see an errno defined for mktime() on > > other systems, but I don't see anything precluding it. Is this something we > > should consider adding to the tz code base? and Ken Pizzini answered: > > The question I have to ask here is: are we working on an ANSI/ISO C > standard compatible interface, or a POSIX/TOG based standard? If > the latter we can work with the understanding that time_t values > represent seconds since some epoch It's my understanding that the current TZ code request it. > and consider following TOG's > lead in saying that negative time_t values are not allowed. OTOH, I don't fell this is requested by the current code base. > But if we are working on something that trancends POSIX compliance > and should work on any standard C system then I don't feel that > we can reasonably rule out negative time_t values -- the C > standard allows far too many possible underlying semanatics > for time_t values. However, we can't aim at full C portability, since the code base made in *many* places the assumption that time_t is an integral type, counting seconds. And the C standard clearly states other implementations are possible. So, as you and Tom point out, we are "between two chairs". > > Is there an existing errno value/macro that > > would fit the description of "time is not representable"? > > The best existing one I see is ERANGE, but the explanitory text > on this system says "Result too large", so it isn't perfect. > (I feel that the description has a bug myself -- a range error > really does encompass more than just "too large" a result.) As the current standard says, this seems correct. ERANGE is used for signaling overflowing of mathematical operations. And the standard explicitly says that it *could* be used for signaling underflows, but doesn't enforce this behavior. If your system don't do it, "Result too large" seems a good description to me. I don't like the idea of re-using ERANGE, because mktime() can fail for others reasons than excessing the available values for time_t (one obvious example is a time in the autumn overloapping period with tm->tm_isdst==-1). I think a new constant is in order (I don't like the idea of a new signaling mechanism); what about EILTIME? Furthermore, since mktime can fail for different reasons (before Epoch, result too large, wrong DST setting, autumn indetermination, spring gap; others?), perhaps can we set up different constants? I also want to bring this discussion to <news:comp.std.c> as well, in part for bringing this to the attention of the members of the comittee in charge of C standardization, in part for asking the C gurus about the choice of an ESOMETHING constant(s). Amicalement, Antoine

1 0

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Tom Peterson (USG) wrote: <from Ken Pizzini> > > A problematical situation on any implementation is distinguishing > > between an error return from mktime() and mktime() returning a > > legitimate -1 value. [...] > > An error code (or errno) would help here I think. If errno were set to a > particular value when mktime() really couldn't represent the value, we'd have > a way to distinguish between a valid -1 and and error -1 return value. I agree with you. > Problem is, we'd have trouble getting the standards like X/Open to accept > this, since they claim they don't support negative time_t's (ie: times before > the Epoch). Strictly speaking, mktime() is not a X/Open standard, but part of the standard C library. So IMHO, the solution lie more in the realm of ISO/JTC2/SC22/WG14 (the comittee in charge of C standardization) than in X/Open. And BTW, ISO C doesn't put any restriction on the range of the value of the time_t (which is only arithmetical, not necessary [un]signed long int); and Epoch does take any sense as long as ISO C is concerned. Best regards, Antoine

1 0

Re: Minute offsets
by ncm＠cantrip.org Jan. 17, 1997

Jan. 17, 1997

The argument that the time format must be obvious by example, so that idiots won't program it wrong, doesn't really apply any more. With the internet, it's easy to find the free code that implements the standard, and given correct free code, people too lazy to read the standard will also be too lazy to rewrite it. Nathan Myers ncm(a)cantrip.org

1 0

My comments on draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

Hello! I am the author of the ISO 8601 summary on http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html and I just found your new Internet draft ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt about a standard date and time notation for the Internet. I agree that such a standard would be very useful and hope to be able to assist you in finishing it. Here are some comments that I wrote down while reading your first draft: 1) You wonder, what standard defines UTC and leap seconds. This standard is ITU-R Recommendation TF.460-4. Using your credit card, you can now order very easily an electronic copy from the International Telecommunication Union Web server http://www.itu.int/itudoc/itu-r/rec/tf.html You'll find there also other related standards regarding UTC and time signal transmission. 2) You suggest in section 3 to implement a rule that assumes for the 2-digit years 50-99 that they belong to the 20th century. Considering that Unix systems cannot represent in time_t any point in time before 1970-01-01 00:00:00Z, and that there are not any electronic documents on the Internet with a timestamp predating 1970, I suggest that 70 is a more reasonable border date. Gives us 20 more years and I expect to be almost dead or at least retired by then. 3) In section 4, you recommend the offset -00:00 to indicate UTC. One might consider the much shorter "Z" notation specified by ISO 8601 for this very common case. Saves a few bytes and is consistent with international radio practice (Z = Zulu = UTC). In section 5.4, you do already allow "Z", so here the text is inconsistent. 4) In section 5.4, you allow the hour value 24. Both 00:00:00 and 24:00:00 are allowed by ISO 8601, but the notation 24:00 identifying the midnight at the end of the day is useful only for time interval notations (e.g., 20:00--24:00) and should not be used for unique timestamps. Better restrict the hour range to 00--23. Times like 24:00:01 definitely violate ISO 8601, but are supported by your grammar. 5) You use the ugly "T" separator between date and time. ISO 8601 supports also the notion of separate date and time fields, so I suggest you simply define your format to consist of a date and a time field separated by a space. This is the ISO 8601 notation used by GNU RCS for instance (see option -zLT). I personally feel that separating date and time field by a space increases human readability and is preferable over the ISO 8601 combined dateTtime field format. 6) In section 6, you suggest an IANA registry of time zone names. Forget this. ;-) Time zone rules and names are thanks to the creativity of our politicians MUCH to dynamic and unstable. For very good reasons, ISO 8601 does not use time zone abbreviations at all. An excellent Internet list of current and historic timezone names that is constantly updated is already available in form of the tz database. You definitely should have a look at this first. <URL:ftp://elsie.nci.nih.gov/pub/tz*>. In addition, your proposal does not use any time zone names (which is a good thing!). 7) You could add a reference to the technical corrigendum 1 for ISO 8601, which fixes a few typos in the standard. 8) You could make the minute part of the time zone optional and require that time zones with an integral number of hours offset to UTC (which are almost all!) should only be represented by a 2-digit offset. That is what GNU RCS does already and I think having only a single colon increases human readability. 9) Feel free to copy my arguments against the ancient 12h am/pm time format from <URL:http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, in order to help eradicate this silly notation from new software (for instance, sendmail still uses am/pm in Received: header lines, which I consider to be very bad Internet time practice). You should also not use the am/pm notation in section 5.5, as the am/pm notation is really a very US-specific idea. The rest of the world has used the 24h notation for many decades and other languages than English do not even have terms like am/pm. I highly recommend you to join the tz(a)elsie.nci.nih.gov mailing list, where you'll meet a number of very experienced Internet date, time, and especially timezone experts. Send e-mail to tz-request(a)elsie.nci.nih.gov to join the club and check ftp://elsie.nci.nih.gov/pub/tzarchive.gz for previous discussion. These are my suggestions for your draft. Please let me know when you have made any changes or have any questions. Thanks for your effort! Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

2 4

Re: C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

In message <32DD304D.40D(a)Renault.FR>, Antoine Leca wrote: > I didn't change anything, but this raises a point: wouldn't it be better > to pass a « time_t const *t » argument? > This is for consistency with other library functions, and portability > (particularly when time_t is a floating type). This rises an interesting question: Why does the C library functions always access time_t values by constant pointers and not by simply copying the value??? I never understood this part of the C lib API. How is portability increased by not using a call-by-value here? If there is any good reason that this has been done in libc, then I'd of course also add it to my code. I already did it for consistency with the existing library functions, but I'd like to know why this is supposed to be the right thing to do. > ¤ Comparing t with 0 doesn't take any sense (I know one system where > ¤ (time_t)0 is J2000,0, so negative t are allowed before 2000-01-01 12:00:00Z Ok, you are right. I just hope that the system you know does not encode 2000-01-01 11:59:59Z = (time_t) -1 as this value is reserved by the standard for error conditions. > ¤ Basically, you can't trust strftime to output what you want if you > ¤ don't set the locale to "C" before. > ¤ I know this code is overkill in the vast majority of cases. I just checked the standard again and it does not indicate that any of the conversion specifiers "%Y-%m-%d %H:%M:%S" depend on the locale. There ARE many conversion specifiers that depend on the locale, but not the above ones, so I understand that we do not have to switch to the "C" locale. > ****** 8601.c > if (prec > 0) { > sprintf(buf, ".%09ld", nsec); > buf += prec + 1; > ****** 8601wrt.c > if (prec > 0) { > int i=9; > while (i-->prec) nsec /= 10; > sprintf(buf, ".%0*ld", prec, nsec); > buf += prec + 1; > ****** > > ¤ I wrote this modification for avoiding a overflow of the buffer. > ¤ You may consider it as unnecessary (but you then may consider > ¤ issuing a warning in the man page). I checked already that nsec is not out of range previously, so I think this additional check is redundant. Thanks for your good comments and also for those I received from others. I'll post the next revision here soon. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

4 3

minor fixes for tzcode1996o
by Todd C. Miller Jan. 16, 1997

Jan. 16, 1997

This fixes potential buffer overflows, corrects getopt(3) usage (getopt(3) returns -1, not EOF these days), and adds another PCTS tweak to pass an arguably bogus test. The diff is reversed, sorry about that. - todd --- time/localtime.c Mon Jan 13 20:17:09 1997 +++ /home/millert/tmp/tzcode1996o/localtime.c Tue Nov 5 11:50:08 1996 @@ -291,10 +276,10 @@ if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; - if ((strlen(p) + strlen(name) + 2) >= sizeof fullname) + if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); @@ -1379,14 +1364,7 @@ dir = tmcomp(&mytm, &yourtm); if (dir != 0) { if (bits-- < 0) -#ifdef PCTS - { - t += 2; - break; - } -#else return WRONG; -#endif if (bits < 0) --t; /* may be needed if new t is minimal */ else if (dir > 0) --- time/zdump.c Mon Jan 13 20:17:17 1997 +++ /home/millert/tmp/tzcode1996o/zdump.c Tue Nov 5 12:00:05 1996 @@ -224,7 +223,6 @@ show(argv[i], t, TRUE); tm = *localtime(&t); (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); - buf[(sizeof buf) - 1] = '\0'; for ( ; ; ) { if (cutoff != NULL && t >= cuttime) break; @@ -241,7 +239,6 @@ newtm = *localtime(&newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); - buf[(sizeof buf) - 1] = '\0'; } t = newt; tm = newtm; @@ -283,7 +280,6 @@ lotm = *localtime(&lot); (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); - loab[(sizeof loab) - 1] = '\0'; while ((hit - lot) >= 2) { t = lot / 2 + hit / 2; if (t <= lot) --- time/zic.c Wed Jan 15 16:41:36 1997 +++ /home/millert/tmp/tzcode1996o/zic.c Fri Dec 27 19:42:04 1996 @@ -478,7 +476,7 @@ (void) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT - 0 */ progname = argv[0]; - while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != -1) + while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF) switch (c) { default: usage();

1 0

Revised C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

Here comes the revised version of my example ISO 8601 output routine. It includes almost all suggestions that I have received plus some more and I have added test calls that should print on all POSIX systems the following: Show time in various forms: Fri Feb 13 18:59:59 2009 2009-02-13 18:59:59-05 2009-02-13 18:59:59.012-05 2009-02-13 23:59:59Z 2009-02-13 23:59:59.012Z 2009-02-13 23:59:60.012Z 2009-02-13 18:59:60-05 2009-02-13 23:59:59+00 2009-02-14 05:14:59+05:15 2009-02-14 05:14:59.012345678+05:15 Show a DST switch (Central Europe, October 1996): 1996-10-26 23:30:00Z = 1996-10-27 01:30:00+02 1996-10-27 00:00:00Z = 1996-10-27 02:00:00+02 1996-10-27 00:30:00Z = 1996-10-27 02:30:00+02 1996-10-27 01:00:00Z = 1996-10-27 02:00:00+01 1996-10-27 01:30:00Z = 1996-10-27 02:30:00+01 1996-10-27 02:00:00Z = 1996-10-27 03:00:00+01 1996-10-27 02:30:00Z = 1996-10-27 03:30:00+01 Thanks for the many valuable suggestions. Since I know now finally, why localtime() uses call-by-reference, I feel very comfortable with breaking the consistency with this legacy interface. Do you see any other portability or elegance problems? Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu /* * Example implementation of the RFC xxxx profile of ISO 8601 * ASCII standard date and time representation in ANSI/ISO C. * * This implementation is only an informal appendix of RFC xxxx and not * part of the standard. This is an early draft version, do not use * this in products yet. * * Please send comments for improvement to * * Markus Kuhn <kuhn(a)cs.purdue.edu> * * Thanks for suggestions to: * * Chris Newman <Chris.Newman(a)innosoft.com> * Ken Pizzini <ken(a)spry.com> * Antoine Leca <Antoine.Leca(a)renault.fr> * * $Id: demo8601.c,v 1.1 1997-01-15 22:02:37-05 kuhn Exp $ */ #include <stdio.h> #include <stdlib.h> #include <time.h> /* * Create an ISO 8601 time string conforming to the RFC xxxx profile * * Input: * * t the time that will be written as returned by time() * utc if true, then UTC instead of local time will be shown * nsec nanoseconds since start of current second or 0 if unknown * prec number of digits (0..9) for decimal fractions of the * second (set to 0 if nsec is unknown) * * Output: * * s time string with strlen(buf) < 36 * * When time_t does not allow to encode leap seconds (like in POSIX), * you can use the value of second 59 in t and add 1000000000 to nsec * in order to represent a leap second. If input or libary errors * are detected, NULL will be returned, otherwise a pointer to the * output string. If buf is NULL, the time string will be written to * a local buffer. This function is not multithreading safe. * * Markus Kuhn <kuhn(a)cs.purdue.edu>, 1997 */ char * create_timestring(char *s, time_t t, int utc, long nsec, unsigned prec) { char *buf, buffer[36]; struct tm ltm, utm, *tmp; long offset; /* safety checks */ s = buf = (s == NULL) ? buffer : s; *buf = '\0'; if (nsec < 0 || nsec > 1999999999L) return NULL; if (prec > 9) prec = 9; /* convert time */ if ((tmp = gmtime(&t)) == NULL) return NULL; utm = ltm = *tmp; if (!utc) ltm = *localtime(&t); /* leap second handling */ if (nsec > 1000000000L) { ltm.tm_sec++; utm.tm_sec++; nsec -= 1000000000L; } /* basic format */ buf += strftime(buf, 20, "%Y-%m-%d %H:%M:%S", utc ? &utm : &ltm); if (prec > 0) { sprintf(buf, ".%09ld", nsec); buf += prec + 1; } /* time zone offset */ if (utc) { *(buf++) = 'Z'; *buf = '\0'; } else { /* we assume without check that the offset is less than 24 hours */ offset = ltm.tm_yday - utm.tm_yday; if (offset > 1) offset = -24; else if (offset < -1) offset = 24; else offset *= 24; offset += ltm.tm_hour - utm.tm_hour; offset *= 60; offset += ltm.tm_min - utm.tm_min; sprintf(buf, "%+03ld", offset / 60); /* hour offset */ buf += 3; if (offset < 0) offset = -offset; offset %= 60; if (offset != 0) sprintf(buf, ":%02ld", offset); /* minute offset */ } return s; } /* Some test code */ int main() { char buf[50]; time_t now; time_t last_dst_hour; int i; puts("Show time in various forms:\n"); now = 1234569599L; /* on POSIX this is 2009-02-13 23:59:59Z */ putenv("TZ=EST5"); puts(ctime(&now)); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 0, 0); puts(buf); create_timestring(buf, now, 1, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 1012345678, 3); puts(buf); /* leap */ create_timestring(buf, now, 0, 1012345678, 0); puts(buf); /* leap */ putenv("TZ=UTC0"); create_timestring(buf, now, 0, 0, 0); puts(buf); putenv("TZ=TST-5:15"); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 9); puts(buf); puts("\nShow a DST switch (Central Europe, October 1996):\n"); last_dst_hour = (((26L * 365) + 6 + 300) * 24) * 3600; putenv("TZ=CET-1CEST,M3.5.0/2,M10.5.0/3"); for (i = -1; i <= 5; i++) { printf("%s = ", create_timestring(NULL, last_dst_hour + i * 1800, 1, 0, 0)); puts(create_timestring(NULL, last_dst_hour + i * 1800, 0, 0, 0)); } return 0; }

1 0

C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 15, 1997

Jan. 15, 1997

I have done a sample implementation of the draft-newman-datetime-00.txt ISO 8601 profile with the modifications suggested by Paul and myself already included. So far, this is only the write routine, the parser will follow later. Please scrutinize the code below such that it becomes highly portable and reliable ANSI/ISO C. I have some doubts whether this code will handle the local time form correctly during both DST switch hours. Does anyone know a nicer solution for determining the UTC offset of local time with portable library functions reliably? (May be, something like "utm.tm_isdst = ltm.tm_isdst" before mktime() is still necessary?) Well-engineered ISO C example code that can easily be included in new applications will certainly make the ISO 8601 profile RFC more popular and should definitely be added. I would also like to see new format specifiers in GNU date (and POSIX.2 date) that would allow me to easily generate the UTC offset fields. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu #include <stdio.h> #include <stdlib.h> #include <time.h> /* * Create an ISO 8601 time string conforming to the RFC xxxx profile * * Input: * * t the time that will be written as returned by clock() * utc if true, then UTC instead of local time will be shown * nsec nanoseconds since start of current second or 0 if unknown * prec number of digits (0..9) for decimal fractions of the * second (set to 0 if nsec is unknown) * * Output: * * buf time string with strlen(buf) < 36 * * When time_t does not allow to encode leap seconds (like in POSIX), * you can use the value of second 59 in t and add 1000000000 to nsec * in order to represent a leap second. If input or libary errors * are detected, buf will be set to be an empty string. This function * is not multithreading safe. * * Markus Kuhn <kuhn(a)cs.purdue.edu>, 1997-01-15 01:00:18-05, early draft */ void create_timestring(char *buf, time_t t, int utc, long nsec, int prec) { struct tm ltm, utm, *tmp; double off; long offset; /* safety checks */ if (buf == NULL) return; *buf = 0; if (t < 0 || nsec < 0 || nsec > 1999999999L) return; if (prec > 9) prec = 9; /* convert time */ if ((tmp = localtime(&t)) == NULL) utc = 1; /* fallback when library does not know local time */ else ltm = *tmp; if ((tmp = gmtime(&t)) == NULL) return; utm = *tmp; /* leap second */ if (nsec > 1000000000L) { ltm.tm_sec++; utm.tm_sec++; nsec -= 1000000000L; } /* basic format */ strftime(buf, 20, "%Y-%m-%d %H:%M:%S", utc ? &utm : &ltm); buf += 19; /* fractional seconds */ if (prec > 0) { sprintf(buf, ".%09ld", nsec); buf += prec + 1; } /* time zone offset */ if (utc) { *(buf++) = 'Z'; *buf = 0; } else { off = difftime(t, mktime(&utm)); if (off < -0.01) { *(buf++) = '-'; offset = -off + 0.5; } else { *(buf++) = '+'; offset = off + 0.5; } offset = (offset + 30) / 60; sprintf(buf, "%02ld", offset / 60); /* hour offset */ buf += 2; offset %= 60; if (offset) sprintf(buf, ":%02ld", offset); /* minute offset */ } return; } int main() { char buf[50]; time_t now; now = time(NULL); puts(ctime(&now)); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 0, 0); puts(buf); create_timestring(buf, now, 1, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 1012345678, 3); puts(buf); create_timestring(buf, now, 0, 12345678, 9); puts(buf); return 0; }

2 1

Re: -00:00 on draft-newman-datetime-00.txt
by David Keegel Jan. 14, 1997

Jan. 14, 1997

To quote some previously private email (with permission): ] On Sun, 12 Jan 1997, David Keegel wrote: ] > Perhaps when ISO-8601 allows different formats (eg: +hh:mm, +hhmm, or +hh) ] > and RFC822 only allows one of these formats, then it would be appropriate ] > to choose the common format (eg: +hhmm). Chris Newman wrote: ] For the "Internet profile", I selected the +hh:mm form. ISO does allow ] the +hhmm form, but one reading of the spec would say only if all ] punctuation is omitted from the rest of the date time format. If all the ] punctuation is omitted, the format becomes basically unreadable. I agree omitting all punctuation would be a Bad Thing. So the question hinges on whether ISO-8601 says you can omit punctuation from the time- zone, without omitting punctuation from everything else. Would anyone on the tz list like to interpret ISO-8601 to answer this? __________________________________________________________________________ David Keegel <djk(a)cyber.com.au> http://www.cyber.com.au/ +61 3 9642-5997 Cybersource P/L: Unix Systems Administration and TCP/IP network management

1 0