change data type for timestamp in Developer lab 2.1.

[dianacarroll]

The solutions used DateTime, which causes an error on insert:

Received exception:
Code: 53. DB::Exception: Type mismatch in IN or VALUES section. Expected: DateTime. Got: Decimal64:  (When parsing Parquet statistics for column TIMESTAMP, physical type 2, column descriptor = {
  name: TIMESTAMP,
  path: TIMESTAMP,
  physical_type: INT64,
  converted_type: TIMESTAMP_MILLIS,
  logical_type: Timestamp(isAdjustedToUTC=true, timeUnit=milliseconds, is_from_converted_type=true, force_set_converted_type=false),
  max_definition_level: 1,
  max_repetition_level: 0,
}. Please report an issue and use input_format_parquet_filter_push_down = false to work around.): (in file/uri datasets-documentation/pypi/2023/pypi_0_7_34.snappy.parquet): While executing ParquetBlockInputFormat: While executing S3Source. (TYPE_MISMATCH)

The DESCRIBE command shows the type in the Parquet file as Nullable(DateTime64). Using DateTime64 in the new table eliminates the error.

Also removed a wayward .DS_Store file from the repo.

[CLAassistant]

All committers have signed the CLA.

[pmusa]

I didn't get this error with the DateTime solution. The dataset timestamp is second based (no ms value), so I think it is good the way it is. Did you get this error on SQL Console?

[dianacarroll]

Yes, I believe I got it in the cloud sql console (it was a while ago).

[pmusa]

I couldn't reproduce it. Shall I close it, or do you want to try it again?

[dianacarroll]

I don't know what you mean by "try again". You are thinking maybe if the issue will be fixed if I run it a few times? It isn't fixed. What DOES fix it is the code change in the PR.

[dianacarroll]

The instructions tell students to use the datatypes used in the inferred schema, minus the Nullable.

The inferred scheme returns Nullable(DataTime64(3)).

So an even better solution would be to use DateTime64(3). I was going for simplicity but if you prefer, let's follow the letter of the instructions. That fixes the issue too.

[pmusa]

I just couldn't reproduce and still can't. Hence the question. Let's look into it together and try to fix it.

[pmusa]

We looked into it, and the error should not happen (the error above is not a training bug). I rather have DateTime instead of DateTime64.