Theory revision 1.11
1This file is in the public domain, so clarified as of 22009-05-17 by Arthur David Olson. 3 4----- Outline ----- 5 6 Time and date functions 7 Scope of the tz database 8 Names of time zone rule files 9 Time zone abbreviations 10 Calendrical issues 11 Time and time zones on Mars 12 13----- Time and date functions ----- 14 15These time and date functions are upwards compatible with POSIX, 16an international standard for UNIX-like systems. 17As of this writing, the current edition of POSIX is: 18 19 Standard for Information technology 20 -- Portable Operating System Interface (POSIX (R)) 21 -- System Interfaces 22 IEEE Std 1003.1, 2004 Edition 23 <http://www.opengroup.org/online-pubs?DOC=7999959899> 24 <http://www.opengroup.org/pubs/catalog/t041.htm> 25 26POSIX has the following properties and limitations. 27 28* In POSIX, time display in a process is controlled by the 29 environment variable TZ. Unfortunately, the POSIX TZ string takes 30 a form that is hard to describe and is error-prone in practice. 31 Also, POSIX TZ strings can't deal with other (for example, Israeli) 32 daylight saving time rules, or situations where more than two 33 time zone abbreviations are used in an area. 34 35 The POSIX TZ string takes the following form: 36 37 stdoffset[dst[offset],date[/time],date[/time]] 38 39 where: 40 41 std and dst 42 are 3 or more characters specifying the standard 43 and daylight saving time (DST) zone names. 44 Starting with POSIX.1-2001, std and dst may also be 45 in a quoted form like "<UTC+10>"; this allows 46 "+" and "-" in the names. 47 offset 48 is of the form `[-]hh:[mm[:ss]]' and specifies the 49 offset west of UTC. The default DST offset is one hour 50 ahead of standard time. 51 date[/time],date[/time] 52 specifies the beginning and end of DST. If this is absent, 53 the system supplies its own rules for DST, and these can 54 differ from year to year; typically US DST rules are used. 55 time 56 takes the form `hh:[mm[:ss]]' and defaults to 02:00. 57 date 58 takes one of the following forms: 59 Jn (1<=n<=365) 60 origin-1 day number not counting February 29 61 n (0<=n<=365) 62 origin-0 day number counting February 29 if present 63 Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12) 64 for the dth day of week n of month m of the year, 65 where week 1 is the first week in which day d appears, 66 and `5' stands for the last week in which day d appears 67 (which may be either the 4th or 5th week). 68 69 Here is an example POSIX TZ string, for US Pacific time using rules 70 appropriate from 1987 through 2006: 71 72 TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00' 73 74 This POSIX TZ string is hard to remember, and mishandles time stamps 75 before 1987 and after 2006. With this package you can use this 76 instead: 77 78 TZ='America/Los_Angeles' 79 80* POSIX does not define the exact meaning of TZ values like "EST5EDT". 81 Typically the current US DST rules are used to interpret such values, 82 but this means that the US DST rules are compiled into each program 83 that does time conversion. This means that when US time conversion 84 rules change (as in the United States in 1987), all programs that 85 do time conversion must be recompiled to ensure proper results. 86 87* In POSIX, there's no tamper-proof way for a process to learn the 88 system's best idea of local wall clock. (This is important for 89 applications that an administrator wants used only at certain times-- 90 without regard to whether the user has fiddled the "TZ" environment 91 variable. While an administrator can "do everything in UTC" to get 92 around the problem, doing so is inconvenient and precludes handling 93 daylight saving time shifts--as might be required to limit phone 94 calls to off-peak hours.) 95 96* POSIX requires that systems ignore leap seconds. 97 98These are the extensions that have been made to the POSIX functions: 99 100* The "TZ" environment variable is used in generating the name of a file 101 from which time zone information is read (or is interpreted a la 102 POSIX); "TZ" is no longer constrained to be a three-letter time zone 103 name followed by a number of hours and an optional three-letter 104 daylight time zone name. The daylight saving time rules to be used 105 for a particular time zone are encoded in the time zone file; 106 the format of the file allows U.S., Australian, and other rules to be 107 encoded, and allows for situations where more than two time zone 108 abbreviations are used. 109 110 It was recognized that allowing the "TZ" environment variable to 111 take on values such as "America/New_York" might cause "old" programs 112 (that expect "TZ" to have a certain form) to operate incorrectly; 113 consideration was given to using some other environment variable 114 (for example, "TIMEZONE") to hold the string used to generate the 115 time zone information file name. In the end, however, it was decided 116 to continue using "TZ": it is widely used for time zone purposes; 117 separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance; 118 and systems where "new" forms of "TZ" might cause problems can simply 119 use TZ values such as "EST5EDT" which can be used both by 120 "new" programs (a la POSIX) and "old" programs (as zone names and 121 offsets). 122 123* To handle places where more than two time zone abbreviations are used, 124 the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst] 125 (where "tmp" is the value the function returns) to the time zone 126 abbreviation to be used. This differs from POSIX, where the elements 127 of tzname are only changed as a result of calls to tzset. 128 129* Since the "TZ" environment variable can now be used to control time 130 conversion, the "daylight" and "timezone" variables are no longer 131 needed. (These variables are defined and set by "tzset"; however, their 132 values will not be used by "localtime.") 133 134* The "localtime" function has been set up to deliver correct results 135 for near-minimum or near-maximum time_t values. (A comment in the 136 source code tells how to get compatibly wrong results). 137 138* A function "tzsetwall" has been added to arrange for the system's 139 best approximation to local wall clock time to be delivered by 140 subsequent calls to "localtime." Source code for portable 141 applications that "must" run on local wall clock time should call 142 "tzsetwall();" if such code is moved to "old" systems that don't 143 provide tzsetwall, you won't be able to generate an executable program. 144 (These time zone functions also arrange for local wall clock time to be 145 used if tzset is called--directly or indirectly--and there's no "TZ" 146 environment variable; portable applications should not, however, rely 147 on this behavior since it's not the way SVR2 systems behave.) 148 149* These functions can account for leap seconds, thanks to Bradley White. 150 151Points of interest to folks with other systems: 152 153* This package is already part of many POSIX-compliant hosts, 154 including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun. 155 On such hosts, the primary use of this package 156 is to update obsolete time zone rule tables. 157 To do this, you may need to compile the time zone compiler 158 `zic' supplied with this package instead of using the system `zic', 159 since the format of zic's input changed slightly in late 1994, 160 and many vendors still do not support the new input format. 161 162* The UNIX Version 7 "timezone" function is not present in this package; 163 it's impossible to reliably map timezone's arguments (a "minutes west 164 of GMT" value and a "daylight saving time in effect" flag) to a 165 time zone abbreviation, and we refuse to guess. 166 Programs that in the past used the timezone function may now examine 167 tzname[localtime(&clock)->tm_isdst] to learn the correct time 168 zone abbreviation to use. Alternatively, use 169 localtime(&clock)->tm_zone if this has been enabled. 170 171* The 4.2BSD gettimeofday function is not used in this package. 172 This formerly let users obtain the current UTC offset and DST flag, 173 but this functionality was removed in later versions of BSD. 174 175* In SVR2, time conversion fails for near-minimum or near-maximum 176 time_t values when doing conversions for places that don't use UTC. 177 This package takes care to do these conversions correctly. 178 179The functions that are conditionally compiled if STD_INSPIRED is defined 180should, at this point, be looked on primarily as food for thought. They are 181not in any sense "standard compatible"--some are not, in fact, specified in 182*any* standard. They do, however, represent responses of various authors to 183standardization proposals. 184 185Other time conversion proposals, in particular the one developed by folks at 186Hewlett Packard, offer a wider selection of functions that provide capabilities 187beyond those provided here. The absence of such functions from this package 188is not meant to discourage the development, standardization, or use of such 189functions. Rather, their absence reflects the decision to make this package 190contain valid extensions to POSIX, to ensure its broad acceptability. If 191more powerful time conversion functions can be standardized, so much the 192better. 193 194 195----- Scope of the tz database ----- 196 197The tz database attempts to record the history and predicted future of 198all computer-based clocks that track civil time. To represent this 199data, the world is partitioned into regions whose clocks all agree 200about time stamps that occur after the somewhat-arbitrary cutoff point 201of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region, 202the database records all known clock transitions, and labels the region 203with a notable location. 204 205Clock transitions before 1970 are recorded for each such location, 206because most POSIX-compatible systems support negative time stamps and 207could misbehave if data were omitted for pre-1970 transitions. 208However, the database is not designed for and does not suffice for 209applications requiring accurate handling of all past times everywhere, 210as it would take far too much effort and guesswork to record all 211details of pre-1970 civil timekeeping. 212 213As noted in the README file, the tz database is not authoritative 214(particularly not for pre-1970 time stamps), and it surely has errors. 215Corrections are welcome and encouraged. Users requiring authoritative 216data should consult national standards bodies and the references cited 217in the database's comments. 218 219 220----- Names of time zone rule files ----- 221 222The time zone rule file naming conventions attempt to strike a balance 223among the following goals: 224 225 * Uniquely identify every national region where clocks have all 226 agreed since 1970. This is essential for the intended use: static 227 clocks keeping local civil time. 228 229 * Indicate to humans as to where that region is. This simplifes use. 230 231 * Be robust in the presence of political changes. This reduces the 232 number of updates and backward-compatibility hacks. For example, 233 names of countries are ordinarily not used, to avoid 234 incompatibilities when countries change their name 235 (e.g. Zaire->Congo) or when locations change countries 236 (e.g. Hong Kong from UK colony to China). 237 238 * Be portable to a wide variety of implementations. 239 This promotes use of the technology. 240 241 * Use a consistent naming convention over the entire world. 242 This simplifies both use and maintenance. 243 244This naming convention is not intended for use by inexperienced users 245to select TZ values by themselves (though they can of course examine 246and reuse existing settings). Distributors should provide 247documentation and/or a simple selection interface that explains the 248names; see the 'tzselect' program supplied with this distribution for 249one example. 250 251Names normally have the form AREA/LOCATION, where AREA is the name 252of a continent or ocean, and LOCATION is the name of a specific 253location within that region. North and South America share the same 254area, `America'. Typical names are `Africa/Cairo', `America/New_York', 255and `Pacific/Honolulu'. 256 257Here are the general rules used for choosing location names, 258in decreasing order of importance: 259 260 Use only valid POSIX file name components (i.e., the parts of 261 names other than `/'). Within a file name component, 262 use only ASCII letters, `.', `-' and `_'. Do not use 263 digits, as that might create an ambiguity with POSIX 264 TZ strings. A file name component must not exceed 14 265 characters or start with `-'. E.g., prefer `Brunei' 266 to `Bandar_Seri_Begawan'. 267 Include at least one location per time zone rule set per country. 268 One such location is enough. Use ISO 3166 (see the file 269 iso3166.tab) to help decide whether something is a country. 270 However, uninhabited ISO 3166 regions like Bouvet Island 271 do not need locations, since local time is not defined there. 272 If all the clocks in a country's region have agreed since 1970, 273 don't bother to include more than one location 274 even if subregions' clocks disagreed before 1970. 275 Otherwise these tables would become annoyingly large. 276 If a name is ambiguous, use a less ambiguous alternative; 277 e.g. many cities are named San Jose and Georgetown, so 278 prefer `Costa_Rica' to `San_Jose' and `Guyana' to `Georgetown'. 279 Keep locations compact. Use cities or small islands, not countries 280 or regions, so that any future time zone changes do not split 281 locations into different time zones. E.g. prefer `Paris' 282 to `France', since France has had multiple time zones. 283 Use mainstream English spelling, e.g. prefer `Rome' to `Roma', and 284 prefer `Athens' to the true name (which uses Greek letters). 285 The POSIX file name restrictions encourage this rule. 286 Use the most populous among locations in a country's time zone, 287 e.g. prefer `Shanghai' to `Beijing'. Among locations with 288 similar populations, pick the best-known location, 289 e.g. prefer `Rome' to `Milan'. 290 Use the singular form, e.g. prefer `Canary' to `Canaries'. 291 Omit common suffixes like `_Islands' and `_City', unless that 292 would lead to ambiguity. E.g. prefer `Cayman' to 293 `Cayman_Islands' and `Guatemala' to `Guatemala_City', 294 but prefer `Mexico_City' to `Mexico' because the country 295 of Mexico has several time zones. 296 Use `_' to represent a space. 297 Omit `.' from abbreviations in names, e.g. prefer `St_Helena' 298 to `St._Helena'. 299 Do not change established names if they only marginally 300 violate the above rules. For example, don't change 301 the existing name `Rome' to `Milan' merely because 302 Milan's population has grown to be somewhat greater 303 than Rome's. 304 If a name is changed, put its old spelling in the `backward' file. 305 306The file `zone.tab' lists the geographical locations used to name 307time zone rule files. It is intended to be an exhaustive list 308of canonical names for geographic regions. 309 310Older versions of this package used a different naming scheme, 311and these older names are still supported. 312See the file `backward' for most of these older names 313(e.g. `US/Eastern' instead of `America/New_York'). 314The other old-fashioned names still supported are 315`WET', `CET', `MET', and `EET' (see the file `europe'). 316 317 318----- Time zone abbreviations ----- 319 320When this package is installed, it generates time zone abbreviations 321like `EST' to be compatible with human tradition and POSIX. 322Here are the general rules used for choosing time zone abbreviations, 323in decreasing order of importance: 324 325 Use abbreviations that consist of three or more ASCII letters. 326 Previous editions of this database also used characters like 327 ' ' and '?', but these characters have a special meaning to 328 the shell and cause commands like 329 set `date` 330 to have unexpected effects. 331 Previous editions of this rule required upper-case letters, 332 but the Congressman who introduced Chamorro Standard Time 333 preferred "ChST", so the rule has been relaxed. 334 335 This rule guarantees that all abbreviations could have 336 been specified by a POSIX TZ string. POSIX 337 requires at least three characters for an 338 abbreviation. POSIX through 2000 says that an abbreviation 339 cannot start with ':', and cannot contain ',', '-', 340 '+', NUL, or a digit. POSIX from 2001 on changes this 341 rule to say that an abbreviation can contain only '-', '+', 342 and alphanumeric characters from the portable character set 343 in the current locale. To be portable to both sets of 344 rules, an abbreviation must therefore use only ASCII 345 letters. 346 347 Use abbreviations that are in common use among English-speakers, 348 e.g. `EST' for Eastern Standard Time in North America. 349 We assume that applications translate them to other languages 350 as part of the normal localization process; for example, 351 a French application might translate `EST' to `HNE'. 352 353 For zones whose times are taken from a city's longitude, use the 354 traditional xMT notation, e.g. `PMT' for Paris Mean Time. 355 The only name like this in current use is `GMT'. 356 357 If there is no common English abbreviation, abbreviate the English 358 translation of the usual phrase used by native speakers. 359 If this is not available or is a phrase mentioning the country 360 (e.g. ``Cape Verde Time''), then: 361 362 When a country has a single or principal time zone region, 363 append `T' to the country's ISO code, e.g. `CVT' for 364 Cape Verde Time. For summer time append `ST'; 365 for double summer time append `DST'; etc. 366 When a country has multiple time zones, take the first three 367 letters of an English place name identifying each zone 368 and then append `T', `ST', etc. as before; 369 e.g. `VLAST' for VLAdivostok Summer Time. 370 371 Use UTC (with time zone abbreviation "zzz") for locations while 372 uninhabited. The "zzz" mnemonic is that these locations are, 373 in some sense, asleep. 374 375Application writers should note that these abbreviations are ambiguous 376in practice: e.g. `EST' has a different meaning in Australia than 377it does in the United States. In new applications, it's often better 378to use numeric UTC offsets like `-0500' instead of time zone 379abbreviations like `EST'; this avoids the ambiguity. 380 381 382----- Calendrical issues ----- 383 384Calendrical issues are a bit out of scope for a time zone database, 385but they indicate the sort of problems that we would run into if we 386extended the time zone database further into the past. An excellent 387resource in this area is Nachum Dershowitz and Edward M. Reingold, 388<a href="http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/"> 389Calendrical Calculations: Third Edition 390</a>, Cambridge University Press (2008). Other information and 391sources are given below. They sometimes disagree. 392 393 394France 395 396Gregorian calendar adopted 1582-12-20. 397French Revolutionary calendar used 1793-11-24 through 1805-12-31, 398and (in Paris only) 1871-05-06 through 1871-05-23. 399 400 401Russia 402 403From Chris Carrier (1996-12-02): 404On 1929-10-01 the Soviet Union instituted an ``Eternal Calendar'' 405with 30-day months plus 5 holidays, with a 5-day week. 406On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the 407Gregorian calendar while retaining the 6-day week; on 1940-06-27 it 408reverted to the 7-day week. With the 6-day week the usual days 409off were the 6th, 12th, 18th, 24th and 30th of the month. 410(Source: Evitiar Zerubavel, _The Seven Day Circle_) 411 412 413Mark Brader reported a similar story in "The Book of Calendars", edited 414by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But: 415 416From: Petteri Sulonen (via Usenet) 417Date: 14 Jan 1999 00:00:00 GMT 418... 419 420If your source is correct, how come documents between 1929 -- 1940 were 421still dated using the conventional, Gregorian calendar? 422 423I can post a scan of a document dated December 1, 1934, signed by 424Yenukidze, the secretary, on behalf of Kalinin, the President of the 425Executive Committee of the Supreme Soviet, if you like. 426 427 428 429Sweden (and Finland) 430 431From: Mark Brader 432<a href="news:1996Jul6.012937.29190@sq.com"> 433Subject: Re: Gregorian reform -- a part of locale? 434</a> 435Date: 1996-07-06 436 437In 1700, Denmark made the transition from Julian to Gregorian. Sweden 438decided to *start* a transition in 1700 as well, but rather than have one of 439those unsightly calendar gaps :-), they simply decreed that the next leap 440year after 1696 would be in 1744 -- putting the whole country on a calendar 441different from both Julian and Gregorian for a period of 40 years. 442 443However, in 1704 something went wrong and the plan was not carried through; 444they did, after all, have a leap year that year. And one in 1708. In 1712 445they gave it up and went back to Julian, putting 30 days in February that 446year!... 447 448Then in 1753, Sweden made the transition to Gregorian in the usual manner, 449getting there only 13 years behind the original schedule. 450 451(A previous posting of this story was challenged, and Swedish readers 452produced the following references to support it: "Tiderakning och historia" 453by Natanael Beckman (1924) and "Tid, en bok om tiderakning och 454kalendervasen" by Lars-Olof Lode'n (no date was given).) 455 456 457Grotefend's data 458 459From: "Michael Palmer" [with one obvious typo fixed] 460Subject: Re: Gregorian Calendar (was Re: Another FHC related question 461Newsgroups: soc.genealogy.german 462Date: Tue, 9 Feb 1999 02:32:48 -800 463... 464 465The following is a(n incomplete) listing, arranged chronologically, of 466European states, with the date they converted from the Julian to the 467Gregorian calendar: 468 46904/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman 470 Catholics and Danzig only) 47109/20 Dec 1582 - France, Lorraine 472 47321 Dec 1582/ 474 01 Jan 1583 - Holland, Brabant, Flanders, Hennegau 47510/21 Feb 1583 - bishopric of Liege (L"uttich) 47613/24 Feb 1583 - bishopric of Augsburg 47704/15 Oct 1583 - electorate of Trier 47805/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg, 479 Salzburg, Brixen 48013/24 Oct 1583 - Austrian Oberelsass and Breisgau 48120/31 Oct 1583 - bishopric of Basel 48202/13 Nov 1583 - duchy of J"ulich-Berg 48302/13 Nov 1583 - electorate and city of K"oln 48404/15 Nov 1583 - bishopric of W"urzburg 48511/22 Nov 1583 - electorate of Mainz 48616/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden 48717/28 Nov 1583 - bishopric of M"unster and duchy of Cleve 48814/25 Dec 1583 - Steiermark 489 49006/17 Jan 1584 - Austria and Bohemia 49111/22 Jan 1584 - Luzern, Uri, Schwyz, Zug, Freiburg, Solothurn 49212/23 Jan 1584 - Silesia and the Lausitz 49322 Jan/ 494 02 Feb 1584 - Hungary (legally on 21 Oct 1587) 495 Jun 1584 - Unterwalden 49601/12 Jul 1584 - duchy of Westfalen 497 49816/27 Jun 1585 - bishopric of Paderborn 499 50014/25 Dec 1590 - Transylvania 501 50222 Aug/ 503 02 Sep 1612 - duchy of Prussia 504 50513/24 Dec 1614 - Pfalz-Neuburg 506 507 1617 - duchy of Kurland (reverted to the Julian calendar in 508 1796) 509 510 1624 - bishopric of Osnabr"uck 511 512 1630 - bishopric of Minden 513 51415/26 Mar 1631 - bishopric of Hildesheim 515 516 1655 - Kanton Wallis 517 51805/16 Feb 1682 - city of Strassburg 519 52018 Feb/ 521 01 Mar 1700 - Protestant Germany (including Swedish possessions in 522 Germany), Denmark, Norway 52330 Jun/ 524 12 Jul 1700 - Gelderland, Zutphen 52510 Nov/ 526 12 Dec 1700 - Utrecht, Overijssel 527 52831 Dec 1700/ 529 12 Jan 1701 - Friesland, Groningen, Z"urich, Bern, Basel, Geneva, 530 Turgau, and Schaffhausen 531 532 1724 - Glarus, Appenzell, and the city of St. Gallen 533 53401 Jan 1750 - Pisa and Florence 535 53602/14 Sep 1752 - Great Britain 537 53817 Feb/ 539 01 Mar 1753 - Sweden 540 5411760-1812 - Graub"unden 542 543The Russian empire (including Finland and the Baltic states) did not 544convert to the Gregorian calendar until the Soviet revolution of 1917. 545 546Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen 547Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend 548(Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28. 549 550 551----- Time and time zones on Mars ----- 552 553Some people have adjusted their work schedules to fit Mars time. 554Dozens of special Mars watches were built for Jet Propulsion 555Laboratory workers who kept Mars time during the Mars Exploration 556Rovers mission (2004). These timepieces look like normal Seikos and 557Citizens but use Mars seconds rather than terrestrial seconds. 558 559A Mars solar day is called a "sol" and has a mean period equal to 560about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is 561divided into a conventional 24-hour clock, so each Mars second equals 562about 1.02749125 terrestrial seconds. 563 564The prime meridian of Mars goes through the center of the crater 565Airy-0, named in honor of the British astronomer who built the 566Greenwich telescope that defines Earth's prime meridian. Mean solar 567time on the Mars prime meridian is called Mars Coordinated Time (MTC). 568 569Each landed mission on Mars has adopted a different reference for 570solar time keeping, so there is no real standard for Mars time zones. 571For example, the Mars Exploration Rover project (2004) defined two 572time zones "Local Solar Time A" and "Local Solar Time B" for its two 573missions, each zone designed so that its time equals local true solar 574time at approximately the middle of the nominal mission. Such a "time 575zone" is not particularly suited for any application other than the 576mission itself. 577 578Many calendars have been proposed for Mars, but none have achieved 579wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a 580sequential count of Mars solar days elapsed since about 1873-12-29 58112:00 GMT. 582 583The tz database does not currently support Mars time, but it is 584documented here in the hopes that support will be added eventually. 585 586Sources: 587 588Michael Allison and Robert Schmunk, 589"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" 590<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-07-30). 591 592Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times 593(2004-01-14), pp A1, A20-A21. 594