teratail
回答率
85.30%
質問するログイン新規登録
トップPython 3.xに関する質問日時情報（年月日時分秒）をできるだけ少ない文字数で表現したい

編集履歴

質問編集履歴

4

base64について気になったことを自分で追記。

2022/03/30 02:33

投稿

marururu
marururu

スコア23

title CHANGED
File without changes
body CHANGED
@@ -1,57 +1,65 @@
1
- ### 前提・実現したいこと
2
-
3
- タイムスタンプを持つとあるデータに対する「時刻情報＋その他情報」による複合キーを、「できるだけ少ない文字数」かつ「どのデータでも同じ文字数」でも表現したいと考えています。
4
- ここで、特に「時刻情報」に関して、何某かの知恵をお借りしたいと思い投稿しました。
5
-
6
- つまり、よくある「yyyy-mm-dd HH:MM:SS」というタイムスタンプから得られる情報をを、できるだけ少ない文字数で表現したいです。
7
-
8
- 例：「yyyy-mm-dd HH:MM:SS（19文字）」→「yyyymmddHHMMSS（14文字）」
9
-
10
- ただ、検索してもあまり情報がなく、自分だけの考察では手一杯な感触を得ています。
11
- そこで、なにか方法がないかお聞きしたく、投稿させていただきました。
12
-
13
- ※検索しても出てこない＝そもそもそんなこと考えずに別の方法を考えるべきだという啓示な気もしますが…
14
-
15
- ### 試したこと
16
-
17
- 日時情報を、UNIX秒に変換する方法と、変換したUNIX秒をn進数に変換する方法を思いつきました。
18
- ※n進数の変換は、一般に用意されるようなアルゴリズムではないと思っているため、別途何某か変換用のスクリプトを組む必要があると思っています。
19
- ※36進数＝0～9,A～Zまでの36文字、62進数＝0～9、a～z、A～Zの62文字、94進数＝ASCII文字33番(0x21)[!]～126番(0x7e)[~]までの94文字と想定しています
20
- ※「データの圧縮」というキーワードから連想し、「可逆圧縮アルゴリズム（ランレングス符号、ハフマン符号、LZ77、LZSS、LZW、Deflateなど）」が使えないかと調べたこともあるのですが、たかだか14文字の数字データを圧縮するような話とは別では…？と思ってしまい、深くは調査しませんでした。
21
-
22
- |概要|桁数|表示データ|範囲|
23
- |:--|:--|:--|
24
- そのまま表記|14桁|2021/09/30 05:16:04|9999年以上
25
- UNIX秒|10桁|1632978964|9,999,999,999(10進数10桁）→'2286-11-21 02:46:39'
26
- UNIX秒を16進数変換|8桁|61554814|0xFFFFFFFF(16進数8桁)→4,294,967,295(UNIX秒)→2106-02-07 15:28:15
27
- UNIX秒を36進数変換|6桁|R08EMS|zzzzzz(36進数)→2038-12-24 05:45:35
28
- UNIX秒を62進数変換|6桁|1MvOqo|ZZZZZZ(62進数)→56,800,235,583(10進数)→3769-12-05 03:13:03
29
- UNIX秒を94進数変換|5桁|7o1RY|~~~~~~(94進数)→7,339,040,223(10進数)→2202-07-26 14:17:03
30
-
31
- ### お聞きしたいこと
32
- 以下の2点についてお聞きしたいです。
33
- 1. **上記アプローチが、あまりにも突拍子のない、変な方法なのかどうか？**
34
- 2. **他に考えられる方法はないか？**
35
-
36
-
37
- おかしな質問かもしれませんが、、何卒よろしくおねがいします。
38
-
39
-
40
- ### 追加検討した結果
41
- #### UNIX秒をオフセットする
42
- UNIX秒は1970/1/1からの経過秒数なので、固定値でオフセットし、2020/1/1からの経過秒数にしてみる。
43
- →表示できる範囲が50年分だけ後ろにオフセットされる。ただし、"桁数"の観点からからいうと、表示できる範囲が変わるわけではないので、長いスパンで考えると大差なく、桁数を削減できるほどの効果は得られないと思われる。
44
-
45
- **0秒＝'1970/1/1'を基準にした場合（通常）　→ 0秒＝'2020/1/1'を基準にし直した場合（工夫あり）**
46
- |桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)|50年分オフセットした場合(終了)
47
- |:--|:--|:--|:--|:--|
48
- 1|0|9|1970/01/01 00:00:00|1970/01/01 00:00:09|2020/01/01 00:00:09
49
- 2|0|99|1970/01/01 00:00:00|1970/01/01 00:01:39|2020/01/01 00:01:39
50
- 3|0|999|1970/01/01 00:00:00|1970/01/01 00:16:39|2020/01/01 00:16:39
51
- 4|0|9999|1970/01/01 00:00:00|1970/01/01 02:46:39|2020/01/01 02:46:39
52
- 5|0|99999|1970/01/01 00:00:00|1970/01/02 03:46:39|2020/01/02 03:46:39
53
- 6|0|999999|1970/01/01 00:00:00|1970/01/12 13:46:39|2020/01/12 13:46:39
54
- 7|0|9999999|1970/01/01 00:00:00|1970/04/26 17:46:39|2020/04/25 17:46:39
55
- 8|0|99999999|1970/01/01 00:00:00|1973/03/03 09:46:39|2023/03/03 09:46:39
56
- 9|0|999999999|1970/01/01 00:00:00|2001/09/09 01:46:39|2051/09/09 01:46:39
57
- 10|0|9999999999|1970/01/01 00:00:00|2286/11/20 17:46:39|2336/11/20 17:46:39
1
+ ### 前提・実現したいこと
2
+
3
+ タイムスタンプを持つとあるデータに対する「時刻情報＋その他情報」による複合キーを、「できるだけ少ない文字数」かつ「どのデータでも同じ文字数」でも表現したいと考えています。
4
+ ここで、特に「時刻情報」に関して、何某かの知恵をお借りしたいと思い投稿しました。
5
+
6
+ つまり、よくある「yyyy-mm-dd HH:MM:SS」というタイムスタンプから得られる情報をを、できるだけ少ない文字数で表現したいです。
7
+
8
+ 例：「yyyy-mm-dd HH:MM:SS（19文字）」→「yyyymmddHHMMSS（14文字）」
9
+
10
+ ただ、検索してもあまり情報がなく、自分だけの考察では手一杯な感触を得ています。
11
+ そこで、なにか方法がないかお聞きしたく、投稿させていただきました。
12
+
13
+ ※検索しても出てこない＝そもそもそんなこと考えずに別の方法を考えるべきだという啓示な気もしますが…
14
+
15
+ ### 試したこと
16
+
17
+ 日時情報を、UNIX秒に変換する方法と、変換したUNIX秒をn進数に変換する方法を思いつきました。
18
+ ※n進数の変換は、一般に用意されるようなアルゴリズムではないと思っているため、別途何某か変換用のスクリプトを組む必要があると思っています。
19
+ ※36進数＝0～9,A～Zまでの36文字、62進数＝0～9、a～z、A～Zの62文字、94進数＝ASCII文字33番(0x21)[!]～126番(0x7e)[~]までの94文字と想定しています
20
+ ※「データの圧縮」というキーワードから連想し、「可逆圧縮アルゴリズム（ランレングス符号、ハフマン符号、LZ77、LZSS、LZW、Deflateなど）」が使えないかと調べたこともあるのですが、たかだか14文字の数字データを圧縮するような話とは別では…？と思ってしまい、深くは調査しませんでした。
21
+
22
+ |概要|桁数|表示データ|範囲|
23
+ |:--|:--|:--|:--|
24
+ |そのまま表記|14桁|2021/09/30 05:16:04|9999年以上|
25
+ |UNIX秒|10桁|1632978964|9,999,999,999(10進数10桁）→'2286-11-21 02:46:39'|
26
+ |UNIX秒を16進数変換|8桁|61554814|0xFFFFFFFF(16進数8桁)→4,294,967,295(UNIX秒)→2106-02-07 15:28:15|
27
+ |UNIX秒を36進数変換|6桁|R08EMS|zzzzzz(36進数)→2038-12-24 05:45:35|
28
+ |UNIX秒を62進数変換|6桁|1MvOqo|ZZZZZZ(62進数)→56,800,235,583(10進数)→3769-12-05 03:13:03|
29
+ |UNIX秒を94進数変換|5桁|7o1RY|~~~~~~(94進数)→7,339,040,223(10進数)→2202-07-26 14:17:03|
30
+
31
+
32
+ ### お聞きしたいこと
33
+ 以下の2点についてお聞きしたいです。
34
+ 1. **上記アプローチが、あまりにも突拍子のない、変な方法なのかどうか？**
35
+ 2. **他に考えられる方法はないか？**
36
+
37
+
38
+ おかしな質問かもしれませんが、、何卒よろしくおねがいします。
39
+
40
+
41
+ ### 追加検討した結果
42
+ #### UNIX秒をオフセットする
43
+ UNIX秒は1970/1/1からの経過秒数なので、固定値でオフセットし、2020/1/1からの経過秒数にしてみる。
44
+ →表示できる範囲が50年分だけ後ろにオフセットされる。ただし、"桁数"の観点からからいうと、表示できる範囲が変わるわけではないので、長いスパンで考えると大差なく、桁数を削減できるほどの効果は得られないと思われる。
45
+
46
+ **0秒＝'1970/1/1'を基準にした場合（通常）　→ 0秒＝'2020/1/1'を基準にし直した場合（工夫あり）**
47
+ |桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)|50年分オフセットした場合(終了)|
48
+ |:--|:--|:--|:--|:--|:--|
49
+ |1|0|9|1970/01/01 00:00:00|1970/01/01 00:00:09|2020/01/01 00:00:09|
50
+ |2|0|99|1970/01/01 00:00:00|1970/01/01 00:01:39|2020/01/01 00:01:39|
51
+ |3|0|999|1970/01/01 00:00:00|1970/01/01 00:16:39|2020/01/01 00:16:39|
52
+ |4|0|9999|1970/01/01 00:00:00|1970/01/01 02:46:39|2020/01/01 02:46:39|
53
+ |5|0|99999|1970/01/01 00:00:00|1970/01/02 03:46:39|2020/01/02 03:46:39|
54
+ |6|0|999999|1970/01/01 00:00:00|1970/01/12 13:46:39|2020/01/12 13:46:39|
55
+ |7|0|9999999|1970/01/01 00:00:00|1970/04/26 17:46:39|2020/04/25 17:46:39|
56
+ |8|0|99999999|1970/01/01 00:00:00|1973/03/03 09:46:39|2023/03/03 09:46:39|
57
+ |9|0|999999999|1970/01/01 00:00:00|2001/09/09 01:46:39|2051/09/09 01:46:39|
58
+ |10|0|9999999999|1970/01/01 00:00:00|2286/11/20 17:46:39|2336/11/20 17:46:39|
59
+
60
+
61
+ #### base64で変換する
62
+ 元のバイナリデータを、アルファベットの小文字（a～zの26文字）とアルファベットの大文字（A～Zの26文字）と数字0～9（の10文字）と「+」と「/」の計64文字を用いた文字列でエンコードするものです。上述で投稿者が勝手に考えた基数変換とは微妙に異なるものだと思っています。
63
+ 使い方としては、「UNIX秒」を「整数型」としていったん「バイナリ」に変換し、base64のルールに則って、「6bitずつ文字列にエンコード」する感じです。
64
+ エンコード結果は4文字区切りでないといけないので、4文字or8文字or12文字…となります。
65
+ 「64文字x8桁」の表現ができれば、281,474,976,710,656(281兆通り）の情報量を持つことができるので、もしミリ秒UNIX秒にしても事足りそうな気がします。
Python 3.xデータベース
Python 3.xデータベース

3

表のデータが間違っていたので修正

2021/11/02 10:57

投稿

marururu
marururu

スコア23

title CHANGED
File without changes
body CHANGED
@@ -23,8 +23,8 @@
23
23
  |:--|:--|:--|
24
24
  そのまま表記|14桁|2021/09/30 05:16:04|9999年以上
25
25
  UNIX秒|10桁|1632978964|9,999,999,999(10進数10桁）→'2286-11-21 02:46:39'
26
- UNIX秒を16進数変換|8桁|61554814|0xFFFFFFFF(16進数8桁)→68,719,476,735(UNIX秒)→4147-08-20 07:32:15
26
+ UNIX秒を16進数変換|8桁|61554814|0xFFFFFFFF(16進数8桁)→4,294,967,295(UNIX秒)→2106-02-07 15:28:15
27
- UNIX秒を36進数変換|6桁|r08ems~|zzzzzz(36進数)→2038-12-24 05:45:35
27
+ UNIX秒を36進数変換|6桁|R08EMS|zzzzzz(36進数)→2038-12-24 05:45:35
28
28
  UNIX秒を62進数変換|6桁|1MvOqo|ZZZZZZ(62進数)→56,800,235,583(10進数)→3769-12-05 03:13:03
29
29
  UNIX秒を94進数変換|5桁|7o1RY|~~~~~~(94進数)→7,339,040,223(10進数)→2202-07-26 14:17:03
30
30
 

2

指摘を反映（93文字→94文字）、ほか表現で誤解を生みそうな箇所を修正

2021/11/02 10:57

投稿

marururu
marururu

スコア23

title CHANGED
File without changes
body CHANGED
@@ -1,9 +1,12 @@
1
1
  ### 前提・実現したいこと
2
2
 
3
- あるデータに対して、ユニークなキーを付与する目的として、「時刻情報」をその一部として利用したいと考えています。
4
- また、この情報は「できるだけ少ない文字数」で、かつ「どのデータでも同じ文字数」で表現したいと考えています。
3
+ タイムスタンプを持つとあるデータに対する「時刻情報＋その他情報」による複合キーを、「できるだけ少ない文字数」かつ「どのデータでも同じ文字数」でも表現したいと考えています。
4
+ ここで、特に「時刻情報」に関して、何某かの知恵をお借りしたいと思い投稿しました。
5
5
 
6
- つまり、よくある「yyyy-mm-dd HH:MM:SS」といった14個の数字を並びを、できるだけ少ない文字数で表現したいです。
6
+ つまり、よくある「yyyy-mm-dd HH:MM:SS」というタイムスタンプから得られる情報をを、できるだけ少ない文字数で表現したいです。
7
+
8
+ 例：「yyyy-mm-dd HH:MM:SS（19文字）」→「yyyymmddHHMMSS（14文字）」
9
+
7
10
  ただ、検索してもあまり情報がなく、自分だけの考察では手一杯な感触を得ています。
8
11
  そこで、なにか方法がないかお聞きしたく、投稿させていただきました。
9
12
 
@@ -13,7 +16,7 @@
13
16
 
14
17
  日時情報を、UNIX秒に変換する方法と、変換したUNIX秒をn進数に変換する方法を思いつきました。
15
18
  ※n進数の変換は、一般に用意されるようなアルゴリズムではないと思っているため、別途何某か変換用のスクリプトを組む必要があると思っています。
16
- ※36進数＝0～9,A～Zまでの36文字、62進数＝0～9、a～z、A～Zの62文字、93進数＝ASCII文字33番(0x21)[!]～126番(0x7e)[~]までの93文字と想定しています
19
+ ※36進数＝0～9,A～Zまでの36文字、62進数＝0～9、a～z、A～Zの62文字、94進数＝ASCII文字33番(0x21)[!]～126番(0x7e)[~]までの94文字と想定しています
17
20
  ※「データの圧縮」というキーワードから連想し、「可逆圧縮アルゴリズム（ランレングス符号、ハフマン符号、LZ77、LZSS、LZW、Deflateなど）」が使えないかと調べたこともあるのですが、たかだか14文字の数字データを圧縮するような話とは別では…？と思ってしまい、深くは調査しませんでした。
18
21
 
19
22
  |概要|桁数|表示データ|範囲|
@@ -21,8 +24,9 @@
21
24
  そのまま表記|14桁|2021/09/30 05:16:04|9999年以上
22
25
  UNIX秒|10桁|1632978964|9,999,999,999(10進数10桁）→'2286-11-21 02:46:39'
23
26
  UNIX秒を16進数変換|8桁|61554814|0xFFFFFFFF(16進数8桁)→68,719,476,735(UNIX秒)→4147-08-20 07:32:15
27
+ UNIX秒を36進数変換|6桁|r08ems~|zzzzzz(36進数)→2038-12-24 05:45:35
24
- UNIX秒を62進数変換|6桁|1MvOqo|ZZZZZZ(62進数)→56800235583(10進数)→3769-12-05 03:13:03
28
+ UNIX秒を62進数変換|6桁|1MvOqo|ZZZZZZ(62進数)→56,800,235,583(10進数)→3769-12-05 03:13:03
25
- UNIX秒を93進数変換|5桁|7o1RY|~~~~~~(93進数)→6956883692(10進数)→2190-06-15 11:41:32
29
+ UNIX秒を94進数変換|5桁|7o1RY|~~~~~~(94進数)→7,339,040,223(10進数)→2202-07-26 14:17:03
26
30
 
27
31
  ### お聞きしたいこと
28
32
  以下の2点についてお聞きしたいです。
@@ -36,33 +40,18 @@
36
40
  ### 追加検討した結果
37
41
  #### UNIX秒をオフセットする
38
42
  UNIX秒は1970/1/1からの経過秒数なので、固定値でオフセットし、2020/1/1からの経過秒数にしてみる。
39
- →桁数の観点からは、文字数の削減にはあまり効果がなさそう…
43
+ →表示できる範囲が50年分だけ後ろにオフセットされる。ただし、"桁数"の観点からからいうと、表示できる範囲が変わるわけではないので、長いスパンで考えると大差なく、桁数を削減できるほどの効果は得られないと思われる。
40
44
 
41
- **0秒＝1970/1/1を基準にした場合**
45
+ **0秒＝'1970/1/1'を基準にした場合（通常）　→ 0秒＝'2020/1/1'を基準にし直した場合（工夫あり）**
42
- |桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)|
46
+ |桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)|50年分オフセットした場合(終了)
43
47
  |:--|:--|:--|:--|:--|
44
- 1|0|9|1970/01/01 00:00:00|1970/01/01 00:00:09
48
+ 1|0|9|1970/01/01 00:00:00|1970/01/01 00:00:09|2020/01/01 00:00:09
45
- 2|0|99|1970/01/01 00:00:00|1970/01/01 00:01:39
49
+ 2|0|99|1970/01/01 00:00:00|1970/01/01 00:01:39|2020/01/01 00:01:39
46
- 3|0|999|1970/01/01 00:00:00|1970/01/01 00:16:39
50
+ 3|0|999|1970/01/01 00:00:00|1970/01/01 00:16:39|2020/01/01 00:16:39
47
- 4|0|9999|1970/01/01 00:00:00|1970/01/01 02:46:39
51
+ 4|0|9999|1970/01/01 00:00:00|1970/01/01 02:46:39|2020/01/01 02:46:39
48
- 5|0|99999|1970/01/01 00:00:00|1970/01/02 03:46:39
52
+ 5|0|99999|1970/01/01 00:00:00|1970/01/02 03:46:39|2020/01/02 03:46:39
49
- 6|0|999999|1970/01/01 00:00:00|1970/01/12 13:46:39
53
+ 6|0|999999|1970/01/01 00:00:00|1970/01/12 13:46:39|2020/01/12 13:46:39
50
- 7|0|9999999|1970/01/01 00:00:00|1970/04/26 17:46:39
54
+ 7|0|9999999|1970/01/01 00:00:00|1970/04/26 17:46:39|2020/04/25 17:46:39
51
- 8|0|99999999|1970/01/01 00:00:00|1973/03/03 09:46:39
55
+ 8|0|99999999|1970/01/01 00:00:00|1973/03/03 09:46:39|2023/03/03 09:46:39
52
- 9|0|999999999|1970/01/01 00:00:00|2001/09/09 01:46:39
56
+ 9|0|999999999|1970/01/01 00:00:00|2001/09/09 01:46:39|2051/09/09 01:46:39
53
- 10|0|9999999999|1970/01/01 00:00:00|2286/11/20 17:46:39
57
+ 10|0|9999999999|1970/01/01 00:00:00|2286/11/20 17:46:39|2336/11/20 17:46:39
54
-
55
-
56
- **0秒＝2020/1/1を基準にした場合**
57
- 桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)
58
- |:--|:--|:--|:--|:--|
59
- 1|0|9|2020/01/01 00:00:00|2020/01/01 00:00:09
60
- 2|0|99|2020/01/01 00:00:00|2020/01/01 00:01:39
61
- 3|0|999|2020/01/01 00:00:00|2020/01/01 00:16:39
62
- 4|0|9999|2020/01/01 00:00:00|2020/01/01 02:46:39
63
- 5|0|99999|2020/01/01 00:00:00|2020/01/02 03:46:39
64
- 6|0|999999|2020/01/01 00:00:00|2020/01/12 13:46:39
65
- 7|0|9999999|2020/01/01 00:00:00|2020/04/25 17:46:39
66
- 8|0|99999999|2020/01/01 00:00:00|2023/03/03 09:46:39
67
- 9|0|999999999|2020/01/01 00:00:00|2051/09/09 01:46:39
68
- 10|0|9999999999|2020/01/01 00:00:00|2336/11/20 17:46:39

1

UNIX秒をオフセットする方法に関する追加検討の内容を追記

2021/10/04 08:54

投稿

marururu
marururu

スコア23

title CHANGED
File without changes
body CHANGED
@@ -30,4 +30,39 @@
30
30
  2. **他に考えられる方法はないか？**
31
31
 
32
32
 
33
- おかしな質問かもしれませんが、、何卒よろしくおねがいします。
33
+ おかしな質問かもしれませんが、、何卒よろしくおねがいします。
34
+
35
+
36
+ ### 追加検討した結果
37
+ #### UNIX秒をオフセットする
38
+ UNIX秒は1970/1/1からの経過秒数なので、固定値でオフセットし、2020/1/1からの経過秒数にしてみる。
39
+ →桁数の観点からは、文字数の削減にはあまり効果がなさそう…
40
+
41
+ **0秒＝1970/1/1を基準にした場合**
42
+ |桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)|
43
+ |:--|:--|:--|:--|:--|
44
+ 1|0|9|1970/01/01 00:00:00|1970/01/01 00:00:09
45
+ 2|0|99|1970/01/01 00:00:00|1970/01/01 00:01:39
46
+ 3|0|999|1970/01/01 00:00:00|1970/01/01 00:16:39
47
+ 4|0|9999|1970/01/01 00:00:00|1970/01/01 02:46:39
48
+ 5|0|99999|1970/01/01 00:00:00|1970/01/02 03:46:39
49
+ 6|0|999999|1970/01/01 00:00:00|1970/01/12 13:46:39
50
+ 7|0|9999999|1970/01/01 00:00:00|1970/04/26 17:46:39
51
+ 8|0|99999999|1970/01/01 00:00:00|1973/03/03 09:46:39
52
+ 9|0|999999999|1970/01/01 00:00:00|2001/09/09 01:46:39
53
+ 10|0|9999999999|1970/01/01 00:00:00|2286/11/20 17:46:39
54
+
55
+
56
+ **0秒＝2020/1/1を基準にした場合**
57
+ 桁数|unix秒(開始)|unix秒(終了)|表現できる範囲(開始)|表現できる範囲(終了)
58
+ |:--|:--|:--|:--|:--|
59
+ 1|0|9|2020/01/01 00:00:00|2020/01/01 00:00:09
60
+ 2|0|99|2020/01/01 00:00:00|2020/01/01 00:01:39
61
+ 3|0|999|2020/01/01 00:00:00|2020/01/01 00:16:39
62
+ 4|0|9999|2020/01/01 00:00:00|2020/01/01 02:46:39
63
+ 5|0|99999|2020/01/01 00:00:00|2020/01/02 03:46:39
64
+ 6|0|999999|2020/01/01 00:00:00|2020/01/12 13:46:39
65
+ 7|0|9999999|2020/01/01 00:00:00|2020/04/25 17:46:39
66
+ 8|0|99999999|2020/01/01 00:00:00|2023/03/03 09:46:39
67
+ 9|0|999999999|2020/01/01 00:00:00|2051/09/09 01:46:39
68
+ 10|0|9999999999|2020/01/01 00:00:00|2336/11/20 17:46:39