[chikamura]

Summary

• Ruby's timestamp_converter outputs epoch seconds for INTEGER/FLOAT (val.to_i/val.to_f), and its DEFAULT_TIMESTAMP_FORMAT has no timezone offset. The java port previously output epoch milliseconds for INTEGER/FLOAT and appended a timezone offset (%:z) to the default STRING format.
• Change INTEGER to output getEpochSecond() and FLOAT to output getEpochSecond() + getNano() / 1e9, matching ruby's to_i/to_f.
• Change default_timestamp_format's @ConfigDefault from "%Y-%m-%d %H:%M:%S.%6N %:z" to "%Y-%m-%d %H:%M:%S.%6N", matching ruby's DEFAULT_TIMESTAMP_FORMAT (this also brings the code in line with README, which already documented the no-offset format).
• Breaking change: existing configs that emit timestamp columns as INTEGER/FLOAT, or as STRING without an explicit timestamp_format, will see different output values/format.

Test plan

• ./gradlew test (added testConvertTimestampToFloat_withFraction to cover the new sub-second FLOAT arithmetic)
• ./gradlew spotlessApply

🤖 Generated with Claude Code

[john-abre]

ありがとうございます。変換ロジックの本体は ruby の value_converter_factory.rb（val.to_i / val.to_f / DEFAULT_TIMESTAMP_FORMAT = "%Y-%m-%d %H:%M:%S.%6N"）と正確に一致しています。1970 年以前の INTEGER の floor 挙動や、現実的な値での FLOAT の精度も ruby と揃っていることを確認しました。破壊的変更が PR 本文と README に明記されている点も良いと思います。

マージ前に対応をお願いしたい点が 2 つあります。

1. timestamp → STRING/DATE/DATETIME で default_timezone が依然として無視されており、デフォルトフォーマットから %:z を外したことでそれが見えなくなっています。BigqueryColumnOption.getTimezone() は "UTC" 固定のデフォルトで、PluginTask.getDefaultTimezone() は src/main のどこからも参照されていません。ruby は @timezone = timezone || default_timezone としています。default_timezone: Asia/Tokyo と column_options: [{name: ts, type: STRING}] の組み合わせで、ruby は 2020-05-01 09:00:00.000000 を出力しますが、このブランチは 2020-05-01 00:00:00.000000 を出力し、オフセットもないためズレに気づけません。既存の問題ではありますが、この PR のタイトルは STRING 出力が ruby と一致すると謳っています。この PR でフォールバックを実装する（column option を Optional<String> + @ConfigDefault("null") にして orElse(task.getDefaultTimezone()) する）か、PR 本文と #122 に「後回しにする」と明記するか、どちらかをお願いします。

2. テストが新しい演算の挙動を固定できていません。 インラインコメントを参照してください。INTEGER のケースは秒単位ぴったりの値を使っているため、切り捨てか四捨五入か、1970 年以前の floor 挙動かが検証されておらず、FLOAT の許容誤差も必要以上に緩くなっています。

ブロッカーではない nit: INTEGER/FLOAT 列でミリ秒に依存していたユーザー向けの移行案内がありません。STRING のユーザーは default_timestamp_format: "%Y-%m-%d %H:%M:%S.%6N %:z" で元に戻せるので、README に一行あると親切です。INTEGER/FLOAT でミリ秒が必要なユーザーには戻す手段がなく、失敗も静かに起きます（下流の TIMESTAMP_MILLIS(col) が 1970 年の日付を返すなど）。

[john-abre]

数行下で使われているタイムゾーン（timezone = columnOption.getTimezone()）は UTC 固定のデフォルトで、ruby の timezone || default_timezone と違い task.getDefaultTimezone() へのフォールバックがありません。デフォルトフォーマットに %:z がなくなったため、default_timezone: Asia/Tokyo を設定しているユーザーは、ruby の出力から 9 時間ズレたタイムゾーンなしの文字列を静かに受け取ることになります。下の DATE / DATETIME 分岐も同様です。ここでフォールバックを実装するか、PR 本文で「後回し」と明記するかをお願いします。

[john-abre]

Nit: この加算は epoch 直近では正しく丸められません。Instant.ofEpochMilli(-1) だと -1 + 0.999 = -0.0010000000000000009 になり、ruby の to_f は -0.001 を返します。実際の日付では差は最大 1 ulp なのでこのままでも問題ありません。完全に一致させたい場合は BigDecimal.valueOf(src.getEpochSecond()).add(BigDecimal.valueOf(src.getNano(), 9)).doubleValue() で実現できます。

[john-abre]

この値は秒単位ぴったりなので、getEpochSecond() でも toEpochMilli() / 1000 でも Math.round(toEpochMilli() / 1000.0) でも通ってしまいます。ruby の to_i と同じ挙動を固定するケースを追加してください。

• ofEpochMilli(1588291200999L) → 1588291200L（四捨五入ではなく切り捨て）
• ofEpochMilli(-1L) → -1L（ゼロ方向の切り捨てではなく floor）

[john-abre]

1588291200L + 123000000 / 1e9 は double として正確に 1588291200.123 になるので、delta は 0.0（または 1e-9）にできます。1970 年以前のケース（ofEpochMilli(-500L) → -0.5）もここに追加しておくと良いと思います。

[chikamura]

@john-abre
Thanks for the detailed review. Addressed in 87d3839, 64bef3d and cd1dffc.

• default_timezone fallback: column_options[].timezone and fields[].timezone are now Optional with a null
  default, and every converter resolves timezone.orElse(task.getDefaultTimezone()) — timestamp → STRING/DATE/DATETIME,
  string → TIMESTAMP/DATE/DATETIME, and nested RECORD fields — matching ruby's timezone || default_timezone. Added tests
  for each path with default_timezone: Asia/Tokyo, plus one confirming a column-level timezone still wins.
• INTEGER tests: testConvertTimestampToInteger now uses …999ms so it pins truncation by itself, and a new
  _floorsBeforeEpoch case covers -1ms → -1.
• FLOAT tests / rounding: tightened the fraction delta to 0.0, and took your BigDecimal suggestion so the sum is
  rounded once like ruby's Time#to_f. The pre-1970 case uses -1ms → -0.001, which covers both the negative value and
  the single-rounding behavior (so I didn't add a separate -500ms case).
• README: added an upgrade note on restoring the previous STRING default via default_timestamp_format: "%Y-%m-%d %H:%M:%S.%6N %:z", and that INTEGER/FLOAT milliseconds cannot be restored (e.g. TIMESTAMP_MILLIS(col) →
  TIMESTAMP_SECONDS(col)).

[john-abre]

@chikamura ありがとうございます！
Blockerはないですが、#124 のマージでの微調整でどう？

（メモ to self: timestamp_formatありtimezone無いカラムはこの修正でdefault_timezoneになりますので、今までJava版プラグインを使っていた顧客の状況は要確認 👀 ）

[chikamura]

@john-abre
Thanks for the proposal. I agree with the direction — sharing the formatter resolution and caching the formatters both make sense.

That said, while we're working through the ruby-compatibility changes, I'd like to keep the scope of feature/ruby-compatibility limited to closing behavioral gaps with the ruby plugin, so I'd prefer to put this PR on hold for now. Once the ruby-compat series has been merged, I'd like to pick this up again, rebased onto feature/ruby-compatibility (or master).

[john-abre]

🙇