~ubuntu-branches/ubuntu/trusty/tzdata/trusty-security : revision 110

1

This file is in the public domain, so clarified as of

2

2009-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

15

These time and date functions are upwards compatible with those of POSIX,

16

an international standard for UNIX-like systems.

17

As of this writing, the current edition of POSIX is:

18

19

The Open Group Base Specifications Issue 7

20

IEEE Std 1003.1, 2013 Edition

21

<http://pubs.opengroup.org/onlinepubs/9699919799/>

22

23

POSIX has the following properties and limitations.

24

25

* In POSIX, time display in a process is controlled by the

26

environment variable TZ. Unfortunately, the POSIX TZ string takes

27

a form that is hard to describe and is error-prone in practice.

28

Also, POSIX TZ strings can't deal with other (for example, Israeli)

29

daylight saving time rules, or situations where more than two

30

time zone abbreviations are used in an area.

31

32

The POSIX TZ string takes the following form:

33

34

stdoffset[dst[offset][,date[/time],date[/time]]]

35

36

where:

37

38

std and dst

39

are 3 or more characters specifying the standard

40

and daylight saving time (DST) zone names.

41

Starting with POSIX.1-2001, std and dst may also be

42

in a quoted form like "<UTC+10>"; this allows

43

"+" and "-" in the names.

44

offset

45

is of the form '[+-]hh:[mm[:ss]]' and specifies the

46

offset west of UT. 'hh' may be a single digit; 0<=hh<=24.

47

The default DST offset is one hour ahead of standard time.

48

date[/time],date[/time]

49

specifies the beginning and end of DST. If this is absent,

50

the system supplies its own rules for DST, and these can

51

differ from year to year; typically US DST rules are used.

52

time

53

takes the form 'hh:[mm[:ss]]' and defaults to 02:00.

54

This is the same format as the offset, except that a

55

leading '+' or '-' is not allowed.

56

date

57

takes one of the following forms:

58

Jn (1<=n<=365)

59

origin-1 day number not counting February 29

60

n (0<=n<=365)

61

origin-0 day number counting February 29 if present

62

Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12)

63

for the dth day of week n of month m of the year,

64

where week 1 is the first week in which day d appears,

65

and '5' stands for the last week in which day d appears

66

(which may be either the 4th or 5th week).

67

Typically, this is the only useful form;

68

the n and Jn forms are rarely used.

69

70

Here is an example POSIX TZ string, for US Pacific time using rules

71

appropriate from 1987 through 2006:

72

73

TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00'

74

75

This POSIX TZ string is hard to remember, and mishandles time stamps

76

before 1987 and after 2006. With this package you can use this

77

instead:

78

79

TZ='America/Los_Angeles'

80

81

* POSIX does not define the exact meaning of TZ values like "EST5EDT".

82

Typically the current US DST rules are used to interpret such values,

83

but this means that the US DST rules are compiled into each program

84

that does time conversion. This means that when US time conversion

85

rules change (as in the United States in 1987), all programs that

86

do time conversion must be recompiled to ensure proper results.

87

88

* In POSIX, there's no tamper-proof way for a process to learn the

89

system's best idea of local wall clock. (This is important for

90

applications that an administrator wants used only at certain times -

91

without regard to whether the user has fiddled the "TZ" environment

92

variable. While an administrator can "do everything in UTC" to get

93

around the problem, doing so is inconvenient and precludes handling

94

daylight saving time shifts - as might be required to limit phone

95

calls to off-peak hours.)

96

97

* POSIX requires that systems ignore leap seconds.

98

99

* The tz code attempts to support all the time_t implementations

100

allowed by POSIX. The time_t type represents a nonnegative count of

101

seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds.

102

In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit

103

signed time_t values stop working after 2038-01-19 03:14:07 UTC, so

104

new implementations these days typically use a signed 64-bit integer.

105

Unsigned 32-bit integers are used on one or two platforms,

106

and 36-bit and 40-bit integers are also used occasionally.

107

Although earlier POSIX versions allowed time_t to be a

108

floating-point type, this was not supported by any practical

109

systems, and POSIX.1-2013 and the tz code both require time_t

110

to be an integer type.

111

112

These are the extensions that have been made to the POSIX functions:

113

114

* The "TZ" environment variable is used in generating the name of a file

115

from which time zone information is read (or is interpreted a la

116

POSIX); "TZ" is no longer constrained to be a three-letter time zone

117

name followed by a number of hours and an optional three-letter

118

daylight time zone name. The daylight saving time rules to be used

119

for a particular time zone are encoded in the time zone file;

120

the format of the file allows U.S., Australian, and other rules to be

121

encoded, and allows for situations where more than two time zone

122

abbreviations are used.

123

124

It was recognized that allowing the "TZ" environment variable to

125

take on values such as "America/New_York" might cause "old" programs

126

(that expect "TZ" to have a certain form) to operate incorrectly;

127

consideration was given to using some other environment variable

128

(for example, "TIMEZONE") to hold the string used to generate the

129

time zone information file name. In the end, however, it was decided

130

to continue using "TZ": it is widely used for time zone purposes;

131

separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance;

132

and systems where "new" forms of "TZ" might cause problems can simply

133

use TZ values such as "EST5EDT" which can be used both by

134

"new" programs (a la POSIX) and "old" programs (as zone names and

135

offsets).

136

137

* To handle places where more than two time zone abbreviations are used,

138

the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst]

139

(where "tmp" is the value the function returns) to the time zone

140

abbreviation to be used. This differs from POSIX, where the elements

141

of tzname are only changed as a result of calls to tzset.

142

143

* Since the "TZ" environment variable can now be used to control time

144

conversion, the "daylight" and "timezone" variables are no longer

145

needed. (These variables are defined and set by "tzset"; however, their

146

values will not be used by "localtime.")

147

148

* The "localtime" function has been set up to deliver correct results

149

for near-minimum or near-maximum time_t values. (A comment in the

150

source code tells how to get compatibly wrong results).

151

152

* A function "tzsetwall" has been added to arrange for the system's

153

best approximation to local wall clock time to be delivered by

154

subsequent calls to "localtime." Source code for portable

155

applications that "must" run on local wall clock time should call

156

"tzsetwall();" if such code is moved to "old" systems that don't

157

provide tzsetwall, you won't be able to generate an executable program.

158

(These time zone functions also arrange for local wall clock time to be

159

used if tzset is called - directly or indirectly - and there's no "TZ"

160

environment variable; portable applications should not, however, rely

161

on this behavior since it's not the way SVR2 systems behave.)

162

163

* Negative time_t values are supported, on systems where time_t is signed.

164

165

* These functions can account for leap seconds, thanks to Bradley White.

166

167

Points of interest to folks with other systems:

168

169

* This package is already part of many POSIX-compliant hosts,

170

including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun.

171

On such hosts, the primary use of this package

172

is to update obsolete time zone rule tables.

173

To do this, you may need to compile the time zone compiler

174

'zic' supplied with this package instead of using the system 'zic',

175

since the format of zic's input changed slightly in late 1994,

176

and many vendors still do not support the new input format.

177

178

* The UNIX Version 7 "timezone" function is not present in this package;

179

it's impossible to reliably map timezone's arguments (a "minutes west

180

of GMT" value and a "daylight saving time in effect" flag) to a

181

time zone abbreviation, and we refuse to guess.

182

Programs that in the past used the timezone function may now examine

183

tzname[localtime(&clock)->tm_isdst] to learn the correct time

184

zone abbreviation to use. Alternatively, use

185

localtime(&clock)->tm_zone if this has been enabled.

186

187

* The 4.2BSD gettimeofday function is not used in this package.

188

This formerly let users obtain the current UTC offset and DST flag,

189

but this functionality was removed in later versions of BSD.

190

191

* In SVR2, time conversion fails for near-minimum or near-maximum

192

time_t values when doing conversions for places that don't use UT.

193

This package takes care to do these conversions correctly.

194

195

The functions that are conditionally compiled if STD_INSPIRED is defined

196

should, at this point, be looked on primarily as food for thought. They are

197

not in any sense "standard compatible" - some are not, in fact, specified in

198

*any* standard. They do, however, represent responses of various authors to

199

standardization proposals.

200

201

Other time conversion proposals, in particular the one developed by folks at

202

Hewlett Packard, offer a wider selection of functions that provide capabilities

203

beyond those provided here. The absence of such functions from this package

204

is not meant to discourage the development, standardization, or use of such

205

functions. Rather, their absence reflects the decision to make this package

206

contain valid extensions to POSIX, to ensure its broad acceptability. If

207

more powerful time conversion functions can be standardized, so much the

208

better.

209

210

211

----- Scope of the tz database -----

212

213

The tz database attempts to record the history and predicted future of

214

all computer-based clocks that track civil time. To represent this

215

data, the world is partitioned into regions whose clocks all agree

216

about time stamps that occur after the somewhat-arbitrary cutoff point

217

of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region,

218

the database records all known clock transitions, and labels the region

219

with a notable location. Although 1970 is a somewhat-arbitrary

220

cutoff, there are significant challenges to moving the cutoff earlier

221

even by a decade or two, due to the wide variety of local practices

222

before computer timekeeping became prevalent.

223

224

Clock transitions before 1970 are recorded for each such location,

225

because most POSIX-compatible systems support negative time stamps and

226

could misbehave if data entries were omitted for pre-1970 transitions.

227

However, the database is not designed for and does not suffice for

228

applications requiring accurate handling of all past times everywhere,

229

as it would take far too much effort and guesswork to record all

230

details of pre-1970 civil timekeeping.

231

232

233

----- Accuracy of the tz database -----

234

235

The tz database is not authoritative, and it surely has errors.

236

Corrections are welcome and encouraged; see the file CONTRIBUTING.

237

Users requiring authoritative data should consult national standards

238

bodies and the references cited in the database's comments.

239

240

Errors in the tz database arise from many sources:

241

242

* The tz database predicts future time stamps, and current predictions

243

will be incorrect after future governments change the rules.

244

For example, if today someone schedules a meeting for 13:00 next

245

October 1, Casablanca time, and tomorrow Morocco changes its

246

daylight saving rules, software can mess up after the rule change

247

if it blithely relies on conversions made before the change.

248

249

* The pre-1970 entries in this database cover only a tiny sliver of how

250

clocks actually behaved; the vast majority of the necessary

251

information was lost or never recorded. Thousands more zones would

252

be needed if the tz database's scope were extended to cover even

253

just the known or guessed history of standard time; for example,

254

the current single entry for France would need to split into dozens

255

of entries, perhaps hundreds.

256

257

* Most of the pre-1970 data entries come from unreliable sources, often

258

astrology books that lack citations and whose compilers evidently

259

invented entries when the true facts were unknown, without

260

reporting which entries were known and which were invented.

261

These books often contradict each other or give implausible entries,

262

and on the rare occasions when they are checked they are

263

typically found to be incorrect.

264

265

* For the UK the tz database relies on years of first-class work done by

266

Joseph Myers and others; see <http://www.polyomino.org.uk/british-time/>.

267

Other countries are not done nearly as well.

268

269

* Sometimes, different people in the same city would maintain clocks

270

that differed significantly. Railway time was used by railroad

271

companies (which did not always agree with each other),

272

church-clock time was used for birth certificates, etc.

273

Often this was merely common practice, but sometimes it was set by law.

274

For example, from 1891 to 1911 the UT offset in France was legally

275

0:09:21 outside train stations and 0:04:21 inside.

276

277

* Although a named location in the tz database stands for the

278

containing region, its pre-1970 data entries are often accurate for

279

only a small subset of that region. For example, Europe/London

280

stands for the United Kingdom, but its pre-1847 times are valid

281

only for locations that have London's exact meridian, and its 1847

282

transition to GMT is known to be valid only for the L&NW and the

283

Caledonian railways.

284

285

* The tz database does not record the earliest time for which a zone's

286

data entries are thereafter valid for every location in the region.

287

For example, Europe/London is valid for all locations in its

288

region after GMT was made the standard time, but the date of

289

standardization (1880-08-02) is not in the tz database, other than

290

in commentary. For many zones the earliest time of validity is

291

unknown.

292

293

* The tz database does not record a region's boundaries, and in many

294

cases the boundaries are not known. For example, the zone

295

America/Kentucky/Louisville represents a region around the city of

296

Louisville, the boundaries of which are unclear.

297

298

* Changes that are modeled as instantaneous transitions in the tz

299

database were often spread out over hours, days, or even decades.

300

301

* Even if the time is specified by law, locations sometimes

302

deliberately flout the law.

303

304

* Early timekeeping practices, even assuming perfect clocks, were

305

often not specified to the accuracy that the tz database requires.

306

307

* Sometimes historical timekeeping was specified more precisely

308

than what the tz database can handle. For example, from 1909 to

309

1937 Netherlands clocks were legally UT+00:19:32.13, but the tz

310

database cannot represent the fractional second.

311

312

* Even when all the timestamp transitions recorded by the tz database

313

are correct, the tz rules that generate them may not faithfully

314

reflect the historical rules. For example, from 1922 until World

315

War II the UK moved clocks forward the day following the third

316

Saturday in April unless that was Easter, in which case it moved

317

clocks forward the previous Sunday. Because the tz database has no

318

way to specify Easter, these exceptional years are entered as

319

separate tz Rule lines, even though the legal rules did not change.

320

321

* The tz database models pre-standard time using the proleptic Gregorian

322

calendar and local mean time (LMT), but many people used other

323

calendars and other timescales. For example, the Roman Empire used

324

the Julian calendar, and had 12 varying-length daytime hours with a

325

non-hour-based system at night.

326

327

* Early clocks were less reliable, and data entries do not represent

328

this unreliability.

329

330

* As for leap seconds, civil time was not based on atomic time before

331

1972, and we don't know the history of earth's rotation accurately

332

enough to map SI seconds to historical solar time to more than

333

about one-hour accuracy. See: Morrison LV, Stephenson FR.

334

Historical values of the Earth's clock error Delta T and the

335

calculation of eclipses. J Hist Astron. 2004;35:327-36

336

<http://adsabs.harvard.edu/full/2004JHA....35..327M>;

337

Historical values of the Earth's clock error. J Hist Astron. 2005;36:339

338

<http://adsabs.harvard.edu/full/2005JHA....36..339M>.

339

340

* The relationship between POSIX time (that is, UTC but ignoring leap

341

seconds) and UTC is not agreed upon after 1972. Although the POSIX

342

clock officially stops during an inserted leap second, at least one

343

proposed standard has it jumping back a second instead; and in

344

practice POSIX clocks more typically either progress glacially during

345

a leap second, or are slightly slowed while near a leap second.

346

347

* The tz database does not represent how uncertain its information is.

348

Ideally it would contain information about when data entries are

349

incomplete or dicey. Partial temporal knowledge is a field of

350

active research, though, and it's not clear how to apply it here.

351

352

In short, many, perhaps most, of the tz database's pre-1970 and future

353

time stamps are either wrong or misleading. Any attempt to pass the

354

tz database off as the definition of time should be unacceptable to

355

anybody who cares about the facts. In particular, the tz database's

356

LMT offsets should not be considered meaningful, and should not prompt

357

creation of zones merely because two locations differ in LMT or

358

transitioned to standard time at different dates.

359

360

361

----- Names of time zone rule files -----

362

363

The time zone rule file naming conventions attempt to strike a balance

364

among the following goals:

365

366

* Uniquely identify every national region where clocks have all

367

agreed since 1970. This is essential for the intended use: static

368

clocks keeping local civil time.

369

370

* Indicate to humans as to where that region is. This simplifies use.

371

372

* Be robust in the presence of political changes. This reduces the

373

number of updates and backward-compatibility hacks. For example,

374

names of countries are ordinarily not used, to avoid

375

incompatibilities when countries change their name

376

(e.g. Zaire->Congo) or when locations change countries

377

(e.g. Hong Kong from UK colony to China).

378

379

* Be portable to a wide variety of implementations.

380

This promotes use of the technology.

381

382

* Use a consistent naming convention over the entire world.

383

This simplifies both use and maintenance.

384

385

This naming convention is not intended for use by inexperienced users

386

to select TZ values by themselves (though they can of course examine

387

and reuse existing settings). Distributors should provide

388

documentation and/or a simple selection interface that explains the

389

names; see the 'tzselect' program supplied with this distribution for

390

one example.

391

392

Names normally have the form AREA/LOCATION, where AREA is the name

393

of a continent or ocean, and LOCATION is the name of a specific

394

location within that region. North and South America share the same

395

area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York',

396

and 'Pacific/Honolulu'.

397

398

Here are the general rules used for choosing location names,

399

in decreasing order of importance:

400

401

Use only valid POSIX file name components (i.e., the parts of

402

names other than '/'). Do not use the file name

403

components '.' and '..'. Within a file name component,

404

use only ASCII letters, '.', '-' and '_'. Do not use

405

digits, as that might create an ambiguity with POSIX

406

TZ strings. A file name component must not exceed 14

407

characters or start with '-'. E.g., prefer 'Brunei'

408

to 'Bandar_Seri_Begawan'. Exceptions: see the discussion

409

of legacy names below.

410

A name must not be empty, or contain '//', or start or end with '/'.

411

Do not use names that differ only in case. Although the reference

412

implementation is case-sensitive, some other implementations

413

are not, and they would mishandle names differing only in case.

414

If one name A is an initial prefix of another name AB (ignoring case),

415

then B must not start with '/', as a regular file cannot have

416

the same name as a directory in POSIX. For example,

417

'America/New_York' precludes 'America/New_York/Bronx'.

418

Uninhabited regions like the North Pole and Bouvet Island

419

do not need locations, since local time is not defined there.

420

There should typically be at least one name for each ISO 3166-1

421

officially assigned two-letter code for an inhabited country

422

or territory.

423

If all the clocks in a region have agreed since 1970,

424

don't bother to include more than one location

425

even if subregions' clocks disagreed before 1970.

426

Otherwise these tables would become annoyingly large.

427

If a name is ambiguous, use a less ambiguous alternative;

428

e.g. many cities are named San José and Georgetown, so

429

prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.

430

Keep locations compact. Use cities or small islands, not countries

431

or regions, so that any future time zone changes do not split

432

locations into different time zones. E.g. prefer 'Paris'

433

to 'France', since France has had multiple time zones.

434

Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and

435

prefer 'Athens' to the Greek 'Αθήνα' or the Romanized 'Athína'.

436

The POSIX file name restrictions encourage this rule.

437

Use the most populous among locations in a zone,

438

e.g. prefer 'Shanghai' to 'Beijing'. Among locations with

439

similar populations, pick the best-known location,

440

e.g. prefer 'Rome' to 'Milan'.

441

Use the singular form, e.g. prefer 'Canary' to 'Canaries'.

442

Omit common suffixes like '_Islands' and '_City', unless that

443

would lead to ambiguity. E.g. prefer 'Cayman' to

444

'Cayman_Islands' and 'Guatemala' to 'Guatemala_City',

445

but prefer 'Mexico_City' to 'Mexico' because the country

446

of Mexico has several time zones.

447

Use '_' to represent a space.

448

Omit '.' from abbreviations in names, e.g. prefer 'St_Helena'

449

to 'St._Helena'.

450

Do not change established names if they only marginally

451

violate the above rules. For example, don't change

452

the existing name 'Rome' to 'Milan' merely because

453

Milan's population has grown to be somewhat greater

454

than Rome's.

455

If a name is changed, put its old spelling in the 'backward' file.

456

This means old spellings will continue to work.

457

458

The file 'zone1970.tab' lists geographical locations used to name time

459

zone rule files. It is intended to be an exhaustive list of names

460

for geographic regions as described above; this is a subset of the

461

names in the data. Although a 'zone1970.tab' location's longitude

462

corresponds to its LMT offset with one hour for every 15 degrees east

463

longitude, this relationship is not exact.

464

465

Older versions of this package used a different naming scheme,

466

and these older names are still supported.

467

See the file 'backward' for most of these older names

468

(e.g., 'US/Eastern' instead of 'America/New_York').

469

The other old-fashioned names still supported are

470

'WET', 'CET', 'MET', and 'EET' (see the file 'europe').

471

472

Older versions of this package defined legacy names that are

473

incompatible with the first rule of location names, but which are

474

still supported. These legacy names are mostly defined in the file

475

'etcetera'. Also, the file 'backward' defines the legacy names

476

'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file

477

'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',

478

'MST7MDT', and 'PST8PDT'.

479

480

Excluding 'backward' should not affect the other data. If

481

'backward' is excluded, excluding 'etcetera' should not affect the

482

remaining data.

483

484

485

----- Time zone abbreviations -----

486

487

When this package is installed, it generates time zone abbreviations

488

like 'EST' to be compatible with human tradition and POSIX.

489

Here are the general rules used for choosing time zone abbreviations,

490

in decreasing order of importance:

491

492

Use abbreviations that consist of three or more ASCII letters.

493

Previous editions of this database also used characters like

494

' ' and '?', but these characters have a special meaning to

495

the shell and cause commands like

496

set `date`

497

to have unexpected effects.

498

Previous editions of this rule required upper-case letters,

499

but the Congressman who introduced Chamorro Standard Time

500

preferred "ChST", so the rule has been relaxed.

501

502

This rule guarantees that all abbreviations could have

503

been specified by a POSIX TZ string. POSIX

504

requires at least three characters for an

505

abbreviation. POSIX through 2000 says that an abbreviation

506

cannot start with ':', and cannot contain ',', '-',

507

'+', NUL, or a digit. POSIX from 2001 on changes this

508

rule to say that an abbreviation can contain only '-', '+',

509

and alphanumeric characters from the portable character set

510

in the current locale. To be portable to both sets of

511

rules, an abbreviation must therefore use only ASCII

512

letters.

513

514

Use abbreviations that are in common use among English-speakers,

515

e.g. 'EST' for Eastern Standard Time in North America.

516

We assume that applications translate them to other languages

517

as part of the normal localization process; for example,

518

a French application might translate 'EST' to 'HNE'.

519

520

For zones whose times are taken from a city's longitude, use the

521

traditional xMT notation, e.g. 'PMT' for Paris Mean Time.

522

The only name like this in current use is 'GMT'.

523

524

If there is no common English abbreviation, abbreviate the English

525

translation of the usual phrase used by native speakers.

526

If this is not available or is a phrase mentioning the country

527

(e.g. "Cape Verde Time"), then:

528

529

When a country is identified with a single or principal zone,

530

append 'T' to the country's ISO code, e.g. 'CVT' for

531

Cape Verde Time. For summer time append 'ST';

532

for double summer time append 'DST'; etc.

533

Otherwise, take the first three letters of an English place

534

name identifying each zone and append 'T', 'ST', etc.

535

as before; e.g. 'VLAST' for VLAdivostok Summer Time.

536

537

Use 'LMT' for local mean time of locations before the introduction

538

of standard time; see "Scope of the tz database".

539

540

Use UT (with time zone abbreviation 'zzz') for locations while

541

uninhabited. The 'zzz' mnemonic is that these locations are,

542

in some sense, asleep.

543

544

Application writers should note that these abbreviations are ambiguous

545

in practice: e.g. 'CST' has a different meaning in China than

546

it does in the United States. In new applications, it's often better

547

to use numeric UT offsets like '-0600' instead of time zone

548

abbreviations like 'CST'; this avoids the ambiguity.

549

550

551

----- Calendrical issues -----

552

553

Calendrical issues are a bit out of scope for a time zone database,

554

but they indicate the sort of problems that we would run into if we

555

extended the time zone database further into the past. An excellent

556

resource in this area is Nachum Dershowitz and Edward M. Reingold,

557

Calendrical Calculations: Third Edition, Cambridge University Press (2008)

558

<http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/>.

559

Other information and sources are given below. They sometimes disagree.

560

561

562

France

563

564

Gregorian calendar adopted 1582-12-20.

565

French Revolutionary calendar used 1793-11-24 through 1805-12-31,

566

and (in Paris only) 1871-05-06 through 1871-05-23.

567

568

569

Russia

570

571

From Chris Carrier (1996-12-02):

572

On 1929-10-01 the Soviet Union instituted an "Eternal Calendar"

573

with 30-day months plus 5 holidays, with a 5-day week.

574

On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the

575

Gregorian calendar while retaining the 6-day week; on 1940-06-27 it

576

reverted to the 7-day week. With the 6-day week the usual days

577

off were the 6th, 12th, 18th, 24th and 30th of the month.

578

(Source: Evitiar Zerubavel, _The Seven Day Circle_)

579

580

581

Mark Brader reported a similar story in "The Book of Calendars", edited

582

by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But:

583

584

From: Petteri Sulonen (via Usenet)

585

Date: 14 Jan 1999 00:00:00 GMT

586

...

587

588

If your source is correct, how come documents between 1929 and 1940 were

589

still dated using the conventional, Gregorian calendar?

590

591

I can post a scan of a document dated December 1, 1934, signed by

592

Yenukidze, the secretary, on behalf of Kalinin, the President of the

593

Executive Committee of the Supreme Soviet, if you like.

594

595

596

597

Sweden (and Finland)

598

599

From: Mark Brader

600

Subject: Re: Gregorian reform - a part of locale?

601

<news:1996Jul6.012937.29190@sq.com>

602

Date: 1996-07-06

603

604

In 1700, Denmark made the transition from Julian to Gregorian. Sweden

605

decided to *start* a transition in 1700 as well, but rather than have one of

606

those unsightly calendar gaps :-), they simply decreed that the next leap

607

year after 1696 would be in 1744 - putting the whole country on a calendar

608

different from both Julian and Gregorian for a period of 40 years.

609

610

However, in 1704 something went wrong and the plan was not carried through;

611

they did, after all, have a leap year that year. And one in 1708. In 1712

612

they gave it up and went back to Julian, putting 30 days in February that

613

year!...

614

615

Then in 1753, Sweden made the transition to Gregorian in the usual manner,

616

getting there only 13 years behind the original schedule.

617

618

(A previous posting of this story was challenged, and Swedish readers

619

produced the following references to support it: "Tideräkning och historia"

620

by Natanael Beckman (1924) and "Tid, en bok om tideräkning och

621

kalenderväsen" by Lars-Olof Lodén (1968).

622

623

624

Grotefend's data

625

626

From: "Michael Palmer" [with one obvious typo fixed]

627

Subject: Re: Gregorian Calendar (was Re: Another FHC related question

628

Newsgroups: soc.genealogy.german

629

Date: Tue, 9 Feb 1999 02:32:48 -800

630

...

631

632

The following is a(n incomplete) listing, arranged chronologically, of

633

European states, with the date they converted from the Julian to the

634

Gregorian calendar:

635

636

04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman

637

Catholics and Danzig only)

638

09/20 Dec 1582 - France, Lorraine

639

640

21 Dec 1582/

641

01 Jan 1583 - Holland, Brabant, Flanders, Hennegau

642

10/21 Feb 1583 - bishopric of Liege (Lüttich)

643

13/24 Feb 1583 - bishopric of Augsburg

644

04/15 Oct 1583 - electorate of Trier

645

05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg,

646

Salzburg, Brixen

647

13/24 Oct 1583 - Austrian Oberelsaß and Breisgau

648

20/31 Oct 1583 - bishopric of Basel

649

02/13 Nov 1583 - duchy of Jülich-Berg

650

02/13 Nov 1583 - electorate and city of Köln

651

04/15 Nov 1583 - bishopric of Würzburg

652

11/22 Nov 1583 - electorate of Mainz

653

16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden

654

17/28 Nov 1583 - bishopric of Münster and duchy of Cleve

655

14/25 Dec 1583 - Steiermark

656

657

06/17 Jan 1584 - Austria and Bohemia

658

11/22 Jan 1584 - Lucerne, Uri, Schwyz, Zug, Freiburg, Solothurn

659

12/23 Jan 1584 - Silesia and the Lausitz

660

22 Jan/

661

02 Feb 1584 - Hungary (legally on 21 Oct 1587)

662

Jun 1584 - Unterwalden

663

01/12 Jul 1584 - duchy of Westfalen

664

665

16/27 Jun 1585 - bishopric of Paderborn

666

667

14/25 Dec 1590 - Transylvania

668

669

22 Aug/

670

02 Sep 1612 - duchy of Prussia

671

672

13/24 Dec 1614 - Pfalz-Neuburg

673

674

1617 - duchy of Kurland (reverted to the Julian calendar in

675

1796)

676

677

1624 - bishopric of Osnabrück

678

679

1630 - bishopric of Minden

680

681

15/26 Mar 1631 - bishopric of Hildesheim

682

683

1655 - Kanton Wallis

684

685

05/16 Feb 1682 - city of Strassburg

686

687

18 Feb/

688

01 Mar 1700 - Protestant Germany (including Swedish possessions in

689

Germany), Denmark, Norway

690

30 Jun/

691

12 Jul 1700 - Gelderland, Zutphen

692

10 Nov/

693

12 Dec 1700 - Utrecht, Overijssel

694

695

31 Dec 1700/

696

12 Jan 1701 - Friesland, Groningen, Zürich, Bern, Basel, Geneva,

697

Turgau, and Schaffhausen

698

699

1724 - Glarus, Appenzell, and the city of St. Gallen

700

701

01 Jan 1750 - Pisa and Florence

702

703

02/14 Sep 1752 - Great Britain

704

705

17 Feb/

706

01 Mar 1753 - Sweden

707

708

1760-1812 - Graubünden

709

710

The Russian empire (including Finland and the Baltic states) did not

711

convert to the Gregorian calendar until the Soviet revolution of 1917.

712

713

Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen

714

Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend

715

(Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28.

716

717

718

----- Time and time zones on Mars -----

719

720

Some people have adjusted their work schedules to fit Mars time.

721

Dozens of special Mars watches were built for Jet Propulsion

722

Laboratory workers who kept Mars time during the Mars Exploration

723

Rovers mission (2004). These timepieces look like normal Seikos and

724

Citizens but use Mars seconds rather than terrestrial seconds.

725

726

A Mars solar day is called a "sol" and has a mean period equal to

727

about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is

728

divided into a conventional 24-hour clock, so each Mars second equals

729

about 1.02749125 terrestrial seconds.

730

731

The prime meridian of Mars goes through the center of the crater

732

Airy-0, named in honor of the British astronomer who built the

733

Greenwich telescope that defines Earth's prime meridian. Mean solar

734

time on the Mars prime meridian is called Mars Coordinated Time (MTC).

735

736

Each landed mission on Mars has adopted a different reference for

737

solar time keeping, so there is no real standard for Mars time zones.

738

For example, the Mars Exploration Rover project (2004) defined two

739

time zones "Local Solar Time A" and "Local Solar Time B" for its two

740

missions, each zone designed so that its time equals local true solar

741

time at approximately the middle of the nominal mission. Such a "time

742

zone" is not particularly suited for any application other than the

743

mission itself.

744

745

Many calendars have been proposed for Mars, but none have achieved

746

wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a

747

sequential count of Mars solar days elapsed since about 1873-12-29

748

12:00 GMT.

749

750

The tz database does not currently support Mars time, but it is

751

documented here in the hopes that support will be added eventually.

752

753

Sources:

754

755

Michael Allison and Robert Schmunk,

756

"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"

757

<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08).

758

759

Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times

760

<http://articles.latimes.com/2004/jan/14/science/sci-marstime14>

761

(2004-01-14), pp A1, A20-A21.

762

763

764

-----

765

Local Variables:

766

coding: utf-8

767

End: