Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

finish the tzdb zic compiler #20

Open
BurntSushi opened this issue Jul 12, 2024 · 1 comment
Open

finish the tzdb zic compiler #20

BurntSushi opened this issue Jul 12, 2024 · 1 comment
Labels
enhancement New feature or request question Further information is requested

Comments

@BurntSushi
Copy link
Owner

In src/tz/zic.rs, there is a complete parser for the zic input format. zic is a tool maintained by the IANA Time Zone Database. It is the tool that converts a plain text description of time zone rules into the binary format used in /usr/share/zoneinfo. For example, here are the DST rules for the United States and the time zone definition of America/New_York (taken from the northamerica file in the data (or complete) tzdb distribution):

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

# Rule	NAME	FROM	TO	-	IN	ON	AT	SAVE	LETTER
Rule	NYC	1920	only	-	Mar	lastSun	2:00	1:00	D
Rule	NYC	1920	only	-	Oct	lastSun	2:00	0	S
Rule	NYC	1921	1966	-	Apr	lastSun	2:00	1:00	D
Rule	NYC	1921	1954	-	Sep	lastSun	2:00	0	S
Rule	NYC	1955	1966	-	Oct	lastSun	2:00	0	S

# Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
		#STDOFF	-4:56:01.6
Zone America/New_York	-4:56:02 -	LMT	1883 Nov 18 17:00u
			-5:00	US	E%sT	1920
			-5:00	NYC	E%sT	1942
			-5:00	US	E%sT	1946
			-5:00	NYC	E%sT	1967
			-5:00	US	E%sT

The src/tz/zic.rs already knows how to parse all of the above. My original plan was to have Jiff support reading from these Zic input files as an alternative to the standard binary TZif based zoneinfo database. But once I got to the point of actually turning the rules into something actionable, I stumbled quite a bit. The zic.c code in particular that I believe we want to port is here.

The main reason for supporting this format (in addition to TZif) is that it is very compact. And potentially opens the door to defining custom time zones via a human readable semi-standard format. It would also hopefully enable jiff-cli to compile its own time zone database without using the tzdb C toolchain, although that isn't nearly as important.

@jhpratt expressed interest in collaborating on this. I think the main issue I see with collaboration here is that I would want the Zic compiler to be inside Jiff itself. In theory, it could be split into a jiff-zic crate or something, but at least as of present, the Zic data types all make pretty extensive use of Jiff's civil time datatypes and ranged integer types. So splitting this out would either mean splitting Zic's civil times into a separate that that both jiff and jiff-zic could depend upon, or it would mean copying at least some parts of the civil time code. (For example, the code that converts between civil time and timestamps, and the code for determining the nth weekday. And maybe other things.)

@BurntSushi BurntSushi added enhancement New feature or request question Further information is requested labels Jul 12, 2024
@jhpratt
Copy link

jhpratt commented Jul 22, 2024

Confirming what I stated privately — I think collaboration on this would make the most sense for the ecosystem. My personal preference is to work with primitive types and tuples thereof, falling back to structs and enums only where strictly necessary. The usage of the latter should remain internal to the various datetime libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants