の今何時ですか？私は時計製造プロジェクトについて説明し始めました。 私はプロジェクトの途中です（私は願っています！）、そしてそれはそれが始まったところとは少し異なります。 以前は、インターネットから時刻を取得することに重点が置かれていました。これは、GPSが信号を受信しない場合でもバックアップとして機能する可能性がありますが、主要な時刻ソースはおそらくGPSです。
ただし、どちらの場合も、時刻は現地時間ではなくUTCとして到着します。 UTCをローカルに変換する方法は、実際のオペレーティングシステムを実行しているコンピューターでは問題になりません。 実際のOSがインストールされると、America / New_Yorkなどのタイムゾーンが提供されます。OSに必要なのはこれだけです（名前、UTCからのオフセット、および夏時間が開始および終了するタイミングに関するデータのテーブルとともに、組み込みです）。 Windows、Mac、およびLinux OSへ。）
The ESP32ベースのクロックは合計で約4MBのメモリしかなく、 FreeRTOS 、小型コンピュータ用のリアルタイムOS。 タイムゾーンの名前からタイムゾーンのルールに変換するためのテーブルは含まれていませんが、ルールは理解しています。 ルールは、UTCからのオフセット、夏時間（夏時間）が観測されるかどうか、および夏時間が開始および停止する時刻を示す短い文字列です。
GPSを備えた時計は、緯度/経度データのタイムゾーンルールへの完全なマップがある場合、それ自体を現地時間に設定できる必要があります。 そのマップを作成し、それを2MB未満にパックすることが、このJSLが行うことです。 コメントは、JSLを使用してランレングスエンコードされたデータのバイナリブロブを構築し、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>インディアナには本当に11のタイムゾーンがありますか？
緯度/経度をタイムゾーンに変換するためにブロブが機能するかどうかを確認するためのテストの一部には、いくつかのマップの作成が含まれます。 このマップのJSLは、リージョン上にデータポイントのグリッドを作成します。 インディアナ州はアメリカ合衆国の真ん中にある州です。それは、東部標準時から中部標準時への変化の端にあります。 Theウィキペディア記事（興味深い読み物）は、タイムゾーンの中心から遠く離れた夏時間がいかに苦痛であり、州内の郡が何年にもわたってさまざまな選択をすることを引き起こしていることを示唆しています。 ゾーン名は、過去に夏時間が開始および停止した時期または停止した時期と微妙な違いがあった可能性があり、東部標準時と中部標準時の間ではそれほど微妙ではありません。 これらのゾーン名（から列）インディアナに表示されます：
New_York, Chicago, and Kentucky zones extend way beyond Indiana.New_York、Chicago、およびKentuckyゾーンは、インディアナをはるかに超えています。
明確なルールは2つだけです（に列）インディアナでの時間。 中部標準時を使用するインディアナの部分は、中部標準時を使用するインディアナ以外の大都市の近くにあります。
Eleven zones in one state.1つの州に11のゾーン。
カンザスのタイムゾーン
カンザスはインディアナの西15度（タイムゾーン全体）であり、西の国境でも同様の問題があります。 4つの郡は、シカゴ（中央）時間ではなくデンバー（山）時間を使用することを選択します。 これにより、郡のアウトラインをテストして、左右の配置だけでなく、上下の配置も確認できます。 ここに示されている状態の概要。 ウィキペディアのカンザスストーリーインディアナほど面白くない（良い！）
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.青いデンバー時間は、カンザス州の西側にある4つの郡で使用されています。 レッドシカゴの時間は、州のほとんどで使用されています。
ESP32へのデータのフラッシュ：
Linux shell window. I should probably rename my computer. I dropped that subscription years ago after I got to the end.Linuxシェルウィンドウ。 私はおそらく私のコンピュータの名前を変更する必要があります。 サブスクリプションを終了した後、数年前にそのサブスクリプションを削除しました。
最後に、 IANAインターネットを機能させる上での彼らの役割に対して。
