在現在是幾奌？我開始描述一個鐘錶製造項目。 我在項目的中途（我希望！），它與它開始的地方有點不同。 以前的重點是從互聯網上獲取時間，如果 GPS 沒有收到信號，它仍然可以作為備用，但主要時間源可能是 GPS。
但是，無論哪種情況，時間都以 UTC 時間到達，而不是本地時間。 在運行真實操作系統的計算機上，如何將 UTC 轉換為本地不是問題。 安裝真正的操作系統時，會提供一個時區，例如 America/New_York 等。這就是操作系統所需要的（以及有關名稱、與 UTC 的偏移量以及夏令時開始和結束時間的數據表，這是內置的Windows、Mac 和 Linux 操作系統。）
這ESP32基於時鐘的總內存只有大約 4MB，並且運行一個版本自由實時操作系統，用於微型計算機的實時操作系統。 它不包括將時區名稱轉換為時區規則的表格，但它確實理解規則。 規則是一個短字符串，指示與 UTC 的偏移量、是否遵守夏令時以及夏令時的開始和結束時間。
如果帶有 GPS 的時鐘具有完整的緯度/經度數據到時區規則的地圖，它應該能夠將自己設置為本地時間。 製作該地圖並將其打包成 <2MB 就是此 JSL 所做的事情。 評論講述了使用 JSL 構建運行長度編碼數據的二進制 blob 以閃存到 ESP32 SoC 上的故事（片上系統.) 代碼第一次運行時需要 if(0) 部分；其中一些需要很長時間，並且在開發代碼時不需要重新運行。 JSL 的各個部分需要運行大約 3 次才能達到最佳壓縮狀態，因為區域繪製的順序發生了變化，這會改變運行代碼的使用次數，這會影響像素在圖中的隱藏方式，因為使用最少最後繪製以確保它們出現。
另外：如果你使用它，分辨率會比 1 英里更差。 做你自己的測試！
/*
Problem one: A GPS device returns both the lat,lon location and the
UTC time. How can you get the local time from that information?
You can't. You also need to know what timezone boundary the lat,lon
falls in. There's a nice github project, updated frequently, with
changes.
https://github.com/evansiroky/timezone-boundary-builder
There's also one or more web sites like
https://timezonedb.com that provide an API to some database similar
to the boundaries.
Problem two: Build a clock using an ESP32 and a GPS. How can it get the
timezone? It only has about 2MB of memory and it can only access the
internet if it has wifi access and a password.
Since a clock should "just work", the internet can be the primary
answer, used if available. A fallback answer is needed too; the data
for the timezones needs to be compressed into a structure that is
small, sufficiently detailed, and reasonably fast. (I probably will
not use the website because I'd have to bake in my API-key...)
Timezones are identified by IANA with names like America/New_York
(no longer Eastern Standard Time, EDT, DST for daylight saving time, etc
because "lots of places have an east.") America/New_York implies
when the time changes happen, but it requires another table to
get those rules. The names change, sometimes, as do the rules.
America/Godthab changed its name to America/Nuuk in 2020, and
everyone has experienced their local leaders playing with "summer time".
https://data.iana.org/time-zones/tzdb/NEWS
Linux systems have another way to represent timezones, using a rule
rather than a name. (Going out on a limb here...) a Linux system has
tables for converting names to rules. A tiny ESP32 system only
understands the rules. A rule looks something like
<-03>3<-02>,M3.5.0/-2,M10.5.0/-1 (for America/Nuuk)
or
EST5EDT,M3.2.0,M11.1.0 (for America/New_York)
I think those are called "posix" rules. EST5 means 5 hours behind
UTC, the EDT means daylight time is observed in the summer. The two
time-like values says when to start and end daylight time using, for
the New York example, third month, second week, sunday with a 2AM default.
Nuuk is 3 or 2 hours behind and uses the last(5) week and 1AM (or
is that 11PM?) Fortunately, we don't need to read or write the rules, the OS does.
The name-based America/New_York and the rule-based EST5EDT,M3.2.0,M11.1.0
provide different benefits for different use cases. The name-based system
uses a database to look up the name and can provide historical information
about whether daylight time was in effect in May of 1970, for example.
The rule-based system needs no database and encodes everything needed
to convert any time the rule covers (maybe not 1970!) between UTC and local.
In this project, I realized a bit late that I needed the rule-based answer;
had the name-based answers been converted to rule-based earlier, collapsing
adjacent names with the same rule into one area instead of several, the
file would be a bit smaller. But, it is small enough.
This is the JSL to build the timezone data structure that is stored
into the ESP32 flash memory (4MB which also holds the C code.) The
C language code on the ESP32 will use the resulting binary data.
*/
// data from https://github.com/evansiroky/timezone-boundary-builder
// https://github.com/evansiroky/timezone-boundary-builder/releases/download/2020d/timezones.geojson.zip
// https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv to convert America/New_York to EST5EDT,M3.2.0,M11.1.0
// https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv
// made my own using the gen-tz.py script, modified with freqCodeToName names added, America/Nuuk was missing
/* here's the import of the file that converts from America/New_York to EST5EDT,M3.2.0,M11.1.0
I open the JMP table with the from and to column names below...
dtTrans = open("f:/ClockScripts/gen-tz.csv",Import Settings(
End Of Line( CRLF, CR, LF ),
End Of Field( Comma, CSV( 1 ) ),
Strip Quotes( 1 ),
Use Apostrophe as Quotation Mark( 0 ),
Use Regional Settings( 0 ),
Scan Whole File( 1 ),
Treat empty columns as numeric( 0 ),
CompressNumericColumns( 0 ),
CompressCharacterColumns( 0 ),
CompressAllowListCheck( 0 ),
Labels( 0 ),
Column Names Start( 1 ),
Data Starts( 1 ),
Lines To Read( "All" ),
Year Rule( "20xx" )
));*/
dtTrans = open("$desktop/timezoneNameConversion.jmp"); // cols from and to, used way below to make an associative array
/* this file was missing Nuuk, above was the regenerated file including Nuuk (run Python on Linux system on the gen-tz)
open("https://raw.githubusercontent.com/nayarsystems/posix_tz_db/master/zones.csv",Import Settings(
End Of Line( CRLF, CR, LF ),
End Of Field( Comma, CSV( 1 ) ),
Strip Quotes( 1 ),
Use Apostrophe as Quotation Mark( 0 ),
Use Regional Settings( 0 ),
Scan Whole File( 1 ),
Treat empty columns as numeric( 0 ),
CompressNumericColumns( 0 ),
CompressCharacterColumns( 0 ),
CompressAllowListCheck( 0 ),
Labels( 0 ),
Column Names Start( 1 ),
Data Starts( 1 ),
Lines To Read( "All" ),
Year Rule( "20xx" )
));
*/
if( 0, // about 2 minutes...run once... download from https://github.com/evansiroky/timezone-boundary-builder/releases/download/2020d/timezones.geojson.zip
za = Open( "z:/timezones.geojson.zip", "zip" );
blob = za << read( "combined.json", Format( blob ) );
p = Parse JSON( Blob To Char( blob ) ); // this grinds for a bit, it is 135MB
Save Text File( "$desktop/rlejson.jsl", char(p) ); // this is what is needed next time
);
/* run the above to generate this file the first time */
P = Eval( Parse( Load Text File( "$desktop/rlejson.jsl" ) ) ); // loads faster this way
/*
this is the only interesting key, grab it once. probably this is what should have been saved/reloaded.
WATER: there is another version of the geojson that includes oceans. I did not look at it. The
JSL presets the bitmap to 0, then fills in polygons with values > 0 for timezones. This works out
well; the C array is indexed from 0 and has a entry for water there. The JSL test code detects
the 0 to avoid an index error and reports "water";
*/
featureList = P["features"]; // list of 426 AAs (no water)
/*
the "P" is for Parsed json. This is the best way to load this .json
data; using the json wizard almost works but does not handle the nested
arrays used to represent disjoint polygons.
The next two files are saved from a prev run. find "if(0, // regenerate" below
to generate them; takes a while and this saves time if nothing else changed.
If you are lucky enough to only run this code once, you won't care. Saved a lot
of development time further down in the file.
*/
rle = Eval( Parse( Load Text File( "$desktop/rletext.jsl" ) ) );
/*
you won't have this file the first time; I think freqCodeToName={"water"}; is the correct choice,
BUT you'll need to do a second run to get good compression! This list *should* have the
"America/New_York" names listed in order of how many times they create a run in the
run length encoding. The 128 most frequent ones get represented as 1-byte codes, the
remaining 300 or so get a 2-byte code. They get counted and saved in this file later.
*/
freqCodeToName = Eval( Parse( Load Text File( "$desktop/rlename.jsl" ) ) );
/*
Mostly this JSL uses the "America/New_York" names, in the order of the feature list.
This simple-minded list of those names can be indexed by the feature index (usually) or
using loc() (rarely) to get the index from the name.
The for loop ignores the geometry for now and make the iFeatureToName list.
*/
iFeatureToName = {};
for( global:iFeature = 1, global:iFeature <= N Items( featureList ), global:iFeature += 1,
tzdata = featureList[global:iFeature]; // aa {"geometry", "properties", "type"}
tzproperties = tzdata["properties"]; // aa ["tzid" => "Africa/Abidjan"]
tzname=tzproperties["tzid"];
insertinto(iFeatureToName,tzname);
if(!contains(freqCodeToName,tzname),
write("\!nadd ",tzname);
insertinto(freqCodeToName, tzname); // see comment above about "freqCodeToName={"water"};" -- this makes the uncompressed version
);
);
// sanity check, will need work or removal in the future.
if( freqCodeToName[1] != "water" | freqCodeToName[2] != "Asia/Shanghai" | freqCodeToName[426] != "Europe/Busingen" | freqCodeToName[427] != "Europe/Vatican",
Throw( "freqCodeToName" ) // probably comment this out on the first run which won't be sorted, and maybe later if the world changes.
);
/*
two helper functions for the graphics script to call
dopoly does one disjoint part of a timezone.
Further down, the graphbox will be recreated over and over for each global:iFeature because
there is an anti-aliased edge that has pixels of a different color than the center pixels
but they are all the same timezone...so doing the timezones one-at-a-time is the easiest way,
though it will take a long time because the bitmap is 16K x 30K huge.
*/
dopoly = function( {tzName, tzcoords},
{i, m, xs,ys},
for( i = 1, i <= N Items( tzcoords ), i += 1,
/*
I'm still not sure what the 2,3,... polys represent. Holes maybe,
in a single disjoint poly. Render same color, smaller polys render later (2nd run).
this is part of the data that is not right with the json wizard (comments at top)
*/
//if(i>1,fillcolor("magenta"));
m = Matrix( tzcoords[i] );
xs = m[0, 1];
ys = m[0, 2];
//pencolor("white");pensize(1);
polygon/*line*/(xs, ys);// xmatrix,ymatrix
)
);
/*
drawpolys does all the disjoint parts of one timezone; a timezone with only 1 part is not nested
quite as deep as a timezone with multiple disjoint parts.
*/
drawpolys = function( {}, //
{tzdata, tzgeometry, tzproperties, tztype, tzGeometryType, tzcoordinates, code, greenbits, bluebits, redbits, ipoly},
tzdata = featureList[global:iFeature]; // aa {"geometry", "properties", "type"}
tzgeometry = tzdata["geometry"]; // aa {"coordinates", "type"}
tzproperties = tzdata["properties"]; // aa ["tzid" => "Africa/Abidjan"]
/* sanity checking, these should match the log line that follows from the driver loop below */
write("\!n drawing ",global:iFeature,": ", tzproperties["tzid"] );
tztype = tzdata["type"]; // string "Feature"
tzGeometryType = tzgeometry["type"];//"Polygon" or "MultiPolygon"
tzcoordinates = tzgeometry["coordinates"]; // list
Fill Color( "white" );
if(
tzGeometryType == "MultiPolygon", /* a disjoint time zone */
for( ipoly = 1, ipoly <= N Items( tzcoordinates ), ipoly += 1,
dopoly( tzproperties["tzid"], tzcoordinates[ipoly] ) /* deeper nest */
);//
, /*else if*/tzGeometryType == "Polygon", /* single poly timezone */
dopoly( tzproperties["tzid"], tzcoordinates );// no extra nest
, /*else*/
Throw( "tzGeometryType" || Char( tzGeometryType ) )
);
);
/*
this needs to run the first time to generate the bitmap to get the initial frequencies of the
run length codes. It needs to run the 2nd time too, using the frequency ordering. Maybe.
Originally 1-pixel zones like Europe/Vatican reported their name. Now they report thier
description, and in this case, the surrounding Europe/Rome has the same description. There
could be some other edge cases that still matter.
"composition" is a large matrix (3.5GB), if rerunning this code, set it to 0 to release the
old one before making a new one. otherwise 2*3.5GB must be in memory at the same time.
*/
composition = 0;
composition = J( 16000, 30000, 0 );42;
if(0, // let this code run to rebuild the composition
for( ifreq = 2/* 1 is water */, ifreq <= N Items( freqCodeToName ), ifreq += 1,
/*
this is the big-to-small list of timezones; get the name of the zone to do next...
*/
thisname=freqCodeToName[ifreq];
/*
this global variable tells the poly routine what to work on; locate the name and use the index from loc
*/
global:iFeature = loc(iFeatureToName,thisname)[1];// draw smallest last
/*
Surprisingly nothing happens when the graphbox is made without a window, until...
*/
gb = Graph Box(
X Scale( -180, 180 ),
Y Scale( -90, 90 ),
framesize( 30000 + 1, 16000 + 1 ), // drawing beyond 30,000 may not always work, 16x30 is about as big as it can be.
<<BACKGROUNDCOLOR>0];
rle = {};
for( irow = 1, irow <= N Rows( composition ), irow += 1,
if(mod(irow,100)==0,write(irow," ");wait(.01));
row = {}; // a list for one row
code = -1; // initial no match
length = 0; // initial no length
for( icol = 1, icol <= N Cols( composition ), icol += 1,
if( composition[irow, icol] != code, // new run begins
if( length > 0, // initial no match has length 0
run = {}; // output code&length of prev run
codecounts[code]+=1;
run[1] = code;
run[2] = length;
row[N Items( row ) + 1] = run;
);
length = 1;
code = composition[irow, icol];//
, // else
length += 1
)
);
run = {};// handle the last one on the row
codecounts[code]+=1;
run[1] = code;
run[2] = length;
row[N Items( row ) + 1] = run;
rle[N Items( rle ) + 1] = Matrix( row );// convert to Nx2 matrix and store at end of rle list
);
countkeys = codecounts<<GETKEYS>0,
iFeatureToName[code];
,//
"water"
)
);
/*
draw a bunch of markers, color coded for timezone, over a map.
This give a view of the accuracy near rivers and obvious political boundaries.
*/
//////////////////////////////////////////////////////////////////
markersOver = function({clat,clon,name,grid=1},
dtVat=New Table( name,
New Column( "tz", Character, "Nominal" ),
New Column( "lat", Numeric, "Continuous", Format( "Best", 12 ) ),
New Column( "lon", Numeric, "Continuous", Format( "Best", 12 ) )
);
for(ylat=clat-.5*grid, ylat<=clat+.5*grid,ylat+=.004*grid,
for(xlon=clon-.5*grid,xlon<=clon+.5*grid,xlon+=.006*grid,
dtVat<<ADDROWS></ADDROWS></GETKEYS></BACKGROUNDCOLOR>印第安納州真的有十一個時區嗎？
測試 blob 是否可以將緯度/經度轉換為時區的部分測試涉及製作一些地圖。 此地圖的 JSL 在一個區域上創建了一個數據點網格。 印第安納州是美國中部的一個州；它正處於從東部時間到中部時間的變化邊緣。 這維基百科文章（有趣的閱讀）表明夏令時是多麼痛苦，遠離時區的中心，導致州內的縣多年來做出不同的選擇。 過去，區域名稱可能與白天時間開始和停止的時間或是否存在細微差別，以及東部時間和中部時間之間的不那麼微妙的選擇。 這些區域名稱（從列）出現在印第安納州：
New_York, Chicago, and Kentucky zones extend way beyond Indiana.New_York、Chicago 和 Kentucky 地區遠遠超出印第安納州。
只有兩個不同的規則（至列）在印第安納州的時間。 印第安納州使用中部時間的部分地區靠近印第安納州以外使用中部時間的大城市。
Eleven zones in one state.一個州有 11 個區域。
堪薩斯時區
堪薩斯州位於印第安納州以西 15 度（整個時區），在其西部邊界也有類似的問題。 四個縣選擇使用丹佛（山區）時間而不是芝加哥（中部）時間。 這對縣輪廓進行了很好的測試，不僅可以查看左右對齊，還可以查看上下對齊。 此處顯示的狀態大綱。 維基百科的堪薩斯故事不像印第安納那樣有趣（好！）
The blue Denver time is used by four counties on the western side of Kansas. The Red Chicago time is used by most of the state.堪薩斯州西部的四個縣使用藍色的丹佛時間。 該州大部分地區使用紅色芝加哥時間。
將數據刷寫到 ESP32：
Linux shell window. I should probably rename my computer. I dropped that subscription years ago after I got to the end.Linux 外殼窗口。 我可能應該重命名我的電腦。 幾年前，我在結束後放棄了該訂閱。
最後，頂一下IANA為他們在使互聯網工作中發揮的作用。
