[FLINK-11010] [TABLE] Flink SQL timestamp is inconsistent with currentProcessingTime() #7180

lamberken · 2018-11-27T08:50:55Z

What is the purpose of the change

the ProcessingTime is just implemented by invoking System.currentTimeMillis() but the long value will be automatically wrapped to a Timestamp with the following statement:
new java.sql.Timestamp(time - TimeZone.getDefault().getOffset(time));

Brief change log

org.apache.flink.table.codegen.CodeGenerator#generateProctimeTimestamp
add Default TimeZone#offset

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (no)

…ingTime()

lamberken · 2018-11-27T08:54:16Z

more discussion details, please read Question about Timestamp in Flink SQL

minimal reproducible example


public static void main(String[] args) throws Exception {

  StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
  StreamTableEnvironment tableEnv = TableEnvironment.getTableEnvironment(env);

  DataStreamSource<String> socket = env.socketTextStream("localhost", 9999);


  tableEnv.registerDataStream("orders", socket, "user,proctime.proctime");

  Table result = tableEnv.sqlQuery("select proctime from orders");
  tableEnv
    .toRetractStream(result, TypeInformation.of(Row.class))
    .addSink(new SinkFunction<Tuple2<Boolean, Row>>() {
        @Override
        public void invoke(Tuple2<Boolean, Row> value, Context context) throws Exception {

            String sysTime = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date());
            String procTime = value.f1.toString();

            System.out.println("sysTime:  " + sysTime );
            System.out.println("procTime: " + procTime );

            System.out.println();

        }
    });
  env.execute();

}

result

sysTime:  2018-11-27 17:29:53.744
procTime: 2018-11-27 09:29:53.744

walterddr

Thanks for the contirbution @lamber-ken , can you kindly add test to justify your change please?

lamberken · 2018-12-02T01:32:15Z

Thanks for review @walterdd. Yes, Ok, I'm very glad to.

read more about Calcite SqlFunctions#internalToTime.

and if I give it an event time with unix timestamp 0, then I got the Timestamp(-28800000). I am confused why internalToTimestamp need to subtract the offset?

walterddr · 2018-12-02T16:56:46Z

Hi @lamber-ken . the minimum reproduction example should be a good starting point for adding test/ITCase to justify your change. I also commented on the JIRA ticket as well.

lamberken · 2018-12-04T09:11:12Z

hi, @walterddr, I had add sql proctime test.

lamberken · 2018-12-04T17:51:52Z

hi, @tillrohrmann, the ci build failed, but I can't find something helpful for me from log, how to rebuild ?
here is ci log detail

lzqdename · 2018-12-06T06:27:38Z

let me show how to generate the wrong result

background: processing time in tumbling window flink:1.5.0

the invoke stack is as follows:
[1] org.apache.calcite.runtime.SqlFunctions.internalToTimestamp (SqlFunctions.java:1,747)
[2] org.apache.flink.table.runtime.aggregate.TimeWindowPropertyCollector.collect (TimeWindowPropertyCollector.scala:53)
[3] org.apache.flink.table.runtime.aggregate.IncrementalAggregateWindowFunction.apply (IncrementalAggregateWindowFunction.scala:74)
[4] org.apache.flink.table.runtime.aggregate.IncrementalAggregateTimeWindowFunction.apply (IncrementalAggregateTimeWindowFunction.scala:72)
[5] org.apache.flink.table.runtime.aggregate.IncrementalAggregateTimeWindowFunction.apply (IncrementalAggregateTimeWindowFunction.scala:39)
[6] org.apache.flink.streaming.runtime.operators.windowing.functions.InternalSingleValueWindowFunction.process (InternalSingleValueWindowFunction.java:46)
[7] org.apache.flink.streaming.runtime.operators.windowing.WindowOperator.emitWindowContents (WindowOperator.java:550)
[8] org.apache.flink.streaming.runtime.operators.windowing.WindowOperator.onProcessingTime (WindowOperator.java:505)
[9] org.apache.flink.streaming.api.operators.HeapInternalTimerService.onProcessingTime (HeapInternalTimerService.java:266)
[10] org.apache.flink.streaming.runtime.tasks.SystemProcessingTimeService$TriggerTask.run (SystemProcessingTimeService.java:281)
[11] java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
[12] java.util.concurrent.FutureTask.run (FutureTask.java:266)
[13] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201 (ScheduledThreadPoolExecutor.java:180)
[14] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:293)
[15] java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,142)
[16] java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
[17] java.lang.Thread.run (Thread.java:748)

now ,we are at [1] org.apache.calcite.runtime.SqlFunctions.internalToTimestamp (SqlFunctions.java:1,747)

and the code is as follows:
public static Timestamp internalToTimestamp(long v) { return new Timestamp(v - LOCAL_TZ.getOffset(v)); }
let us print the value of windowStart:v
print v
v = 1544074830000
let us print the value of windowEnd:v
print v
v = 1544074833000

after this, come back to
[1] org.apache.flink.table.runtime.aggregate.TimeWindowPropertyCollector.collect (TimeWindowPropertyCollector.scala:51)

then,we will execute
`
if (windowStartOffset.isDefined) {
output.setField(
lastFieldPos + windowStartOffset.get,
SqlFunctions.internalToTimestamp(windowStart))
}

if (windowEndOffset.isDefined) {
output.setField(
lastFieldPos + windowEndOffset.get,
SqlFunctions.internalToTimestamp(windowEnd))
}
`

before execute,the output is
output = "pro0,throwable0,ERROR,ip0,1,ymm-appmetric-dev-self1_5_924367729,null,null,null"
after execute,the output is
output = "pro0,throwable0,ERROR,ip0,1,ymm-appmetric-dev-self1_5_924367729,2018-12-06 05:40:30.0,2018-12-06 05:40:33.0,null"

so,do you think the
long value 1544074830000 translated to be 2018-12-06 05:40:30.0
long value 1544074833000 translated to be 2018-12-06 05:40:33.0
would be right?

I am in China, I think the timestamp should be 2018-12-06 13:40:30.0 and 2018-12-06 13:40:33.0

okay,let us continue

now ,the data will be written to kafka,before write ,the data will be serialized
let us see what happened!

the call stack is as follows:
[1] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ser.std.DateSerializer._timestamp (DateSerializer.java:41)
[2] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ser.std.DateSerializer.serialize (DateSerializer.java:48)
[3] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ser.std.DateSerializer.serialize (DateSerializer.java:15)
[4] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue (DefaultSerializerProvider.java:130)
[5] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ObjectMapper.writeValue (ObjectMapper.java:2,444)
[6] org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ObjectMapper.valueToTree (ObjectMapper.java:2,586)
[7] org.apache.flink.formats.json.JsonRowSerializationSchema.convert (JsonRowSerializationSchema.java:189)
[8] org.apache.flink.formats.json.JsonRowSerializationSchema.convertRow (JsonRowSerializationSchema.java:128)
[9] org.apache.flink.formats.json.JsonRowSerializationSchema.serialize (JsonRowSerializationSchema.java:102)
[10] org.apache.flink.formats.json.JsonRowSerializationSchema.serialize (JsonRowSerializationSchema.java:51)
[11] org.apache.flink.streaming.util.serialization.KeyedSerializationSchemaWrapper.serializeValue (KeyedSerializationSchemaWrapper.java:46)
[12] org.apache.flink.streaming.connectors.kafka.FlinkKafkaProducer010.invoke (FlinkKafkaProducer010.java:355)
[13] org.apache.flink.streaming.api.operators.StreamSink.processElement (StreamSink.java:56)
[14] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator (OperatorChain.java:560)
[15] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:535)
[16] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:515)
[17] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:679)
[18] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:657)
[19] org.apache.flink.streaming.api.operators.StreamMap.processElement (StreamMap.java:41)
[20] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator (OperatorChain.java:560)
[21] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:535)
[22] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:515)
[23] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:679)
[24] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:657)
[25] org.apache.flink.streaming.api.operators.TimestampedCollector.collect (TimestampedCollector.java:51)
[26] org.apache.flink.table.runtime.CRowWrappingCollector.collect (CRowWrappingCollector.scala:37)
[27] org.apache.flink.table.runtime.CRowWrappingCollector.collect (CRowWrappingCollector.scala:28)
[28] DataStreamCalcRule$88.processElement (null)
[29] org.apache.flink.table.runtime.CRowProcessRunner.processElement (CRowProcessRunner.scala:66)
[30] org.apache.flink.table.runtime.CRowProcessRunner.processElement (CRowProcessRunner.scala:35)
[31] org.apache.flink.streaming.api.operators.ProcessOperator.processElement (ProcessOperator.java:66)
[32] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator (OperatorChain.java:560)
[33] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:535)
[34] org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect (OperatorChain.java:515)
[35] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:679)
[36] org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect (AbstractStreamOperator.java:657)
[37] org.apache.flink.streaming.api.operators.TimestampedCollector.collect (TimestampedCollector.java:51)
[38] org.apache.flink.table.runtime.aggregate.TimeWindowPropertyCollector.collect (TimeWindowPropertyCollector.scala:65)
[39] org.apache.flink.table.runtime.aggregate.IncrementalAggregateWindowFunction.apply (IncrementalAggregateWindowFunction.scala:74)
[40] org.apache.flink.table.runtime.aggregate.IncrementalAggregateTimeWindowFunction.apply (IncrementalAggregateTimeWindowFunction.scala:72)
[41] org.apache.flink.table.runtime.aggregate.IncrementalAggregateTimeWindowFunction.apply (IncrementalAggregateTimeWindowFunction.scala:39)
[42] org.apache.flink.streaming.runtime.operators.windowing.functions.InternalSingleValueWindowFunction.process (InternalSingleValueWindowFunction.java:46)
[43] org.apache.flink.streaming.runtime.operators.windowing.WindowOperator.emitWindowContents (WindowOperator.java:550)
[44] org.apache.flink.streaming.runtime.operators.windowing.WindowOperator.onProcessingTime (WindowOperator.java:505)
[45] org.apache.flink.streaming.api.operators.HeapInternalTimerService.onProcessingTime (HeapInternalTimerService.java:266)
[46] org.apache.flink.streaming.runtime.tasks.SystemProcessingTimeService$TriggerTask.run (SystemProcessingTimeService.java:281)
[47] java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
[48] java.util.concurrent.FutureTask.run (FutureTask.java:266)
[49] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201 (ScheduledThreadPoolExecutor.java:180)
[50] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:293)
[51] java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,142)
[52] java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
[53] java.lang.Thread.run (Thread.java:748)

and the code is as follows:
protected long _timestamp(Date value)
{
return value == null ? 0L : value.getTime();
}

here,use windowEnd for example,the value is
value = "2018-12-06 05:40:33.0"
value.getTime() = 1544046033000

see,the initial value is 1544074833000 and the final value is 1544046033000

the minus value is 28800000, ---> 8 hours ,because I am in China.

why? the key reason is SqlFunctions.internalToTimestamp
public static Timestamp internalToTimestamp(long v)
{
return new Timestamp(v - LOCAL_TZ.getOffset(v));
}

in the code, It minus the LOCAL_TZ , I think it is redundant!

lamberken · 2018-12-06T07:23:06Z

@lzqdename, thanks for your detail description.

Jennifer-sarah · 2018-12-07T01:38:49Z

+1, from my side. I had the same problem. thanks

walterddr · 2018-12-07T02:38:35Z

Hi @lamber-ken sorry for the late response. I am a bit confuse with the JIRA ticket description and the PR comments.

I am under the impression that the goal should make all internal times GMT-based regardless of where the code runs. Thus currentProcessingTime() should return a GMT-based time. if my understanding is correct, shouldn't the fix be in the "timerService" side instead?

lamberken · 2018-12-07T03:17:36Z

@walterddr, you are welcome.
flink sql use CodeGenerator#generateProctimeTimestamp method to process proctime and its type is Timestamp, flink use calcite to convert long to Timestamp

but calcite implementation of the method as below, SqlFunctions#internalToTime

public static java.sql.Time internalToTime(int v) {
    return new java.sql.Time(v - LOCAL_TZ.getOffset(v));
}

lzqdename · 2018-12-10T04:08:06Z

In the Flink
to get process time ,the result is OK
then , In the Flink,the result is transfromed several times
for example , Long ->Timestamp ->Long->Timestamp

when Long ->Timestamp,use code as follows:[In SqlFunctions]
public static java.sql.Time internalToTime(int v) {
return new java.sql.Time(v - LOCAL_TZ.getOffset(v));
}

when Timestamp->Long,use code as follows:[In SqlFunctions]
// mainly intended for java.sql.Timestamp but works for other dates also
public static long toLong(java.util.Date v, TimeZone timeZone) {
final long time = v.getTime();
return time + timeZone.getOffset(time);
}

In the final write step,
Timestamp to Long
use code as follows:
protected long _timestamp(Date value) {
return value == null ? 0L : value.getTime();
}
the position is :org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ser.std.DateSerializer._timestamp (DateSerializer.java:41)

now ,let me think, we use two different class to handle the transformation between Long and Timestamp,
and the first class SqlFunctions imports TimeZone factor,
but the second class ,TimeZone factor not imported

It is not consitent when handling time transformation!

lamberken · 2018-12-10T06:07:36Z

hi, @twalthr, @dawidwys, cc or talk about it, thanks. :)

AdolphKK · 2018-12-10T15:28:52Z

@lamber-ken thanks, it looks good to me. Our servers are in EST zone and this problem has been bothering me for a long time.

samsai · 2018-12-11T01:45:53Z

i got the same problem too:
val format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ssZ")
val origin: DataStream[TransactionEvent] = env.fromCollection(List(
TransactionEvent("u1", format.parse("2018-01-02 01:13:30+0800"), 10)
))
val source2 = origin
.assignTimestampsAndWatermarks(new BoundedOutOfOrdernessTimestampExtractorTransactionEvent{
override def extractTimestamp(element: TransactionEvent): Long = {
val timestamp = element.time.getTime
println(s"extractTimestamp:$timestamp")
timestamp
}
})
tEnv.fromDataStream(source2, 'user,'eventTime.rowtime)
.toAppendStream[Row].print()

I got eventTime as 2018-01-01 17:13:30.0, which is 8hours delayed

lamberken · 2018-12-11T02:36:39Z

hi, @zentol cc

walterddr

Hi @lamber-ken thanks for the explanation. I am still concern whether this is the best solution to the problem by working backwards from Calcite. I tagged https://issues.apache.org/jira/browse/FLINK-8353 as a more well structured plan to add timezone support to FLINK.

walterddr · 2018-12-11T04:34:13Z

...aries/flink-table/src/test/java/org/apache/flink/table/runtime/stream/sql/JavaSqlITCase.java

+					Timestamp procTimestamp = (Timestamp) value.getField(0);
+
+					// validate the second here
+					long procSecondTime = procTimestamp.getTime() / 1000;


This causes me some trouble because cases can happen when they cross the second boundary. this is not a stable ITCase in my opinion.

yeah, it's better to validate hour. I'll update.

lamberken · 2018-12-11T16:23:13Z

@walterddr, as the https://issues.apache.org/jira/browse/FLINK-8353 desc.

need to modify each function which works with sql proctiome.
it's not user-friendly, because user need to use udf function to convert proctime.
flink sql shoud consistent with flink-jar program which user do not need to care the default timezone.

samsai · 2018-12-12T03:05:30Z

@walterddr could you please check the timezone problem when dealing with eventtime?
it seems that lamber-ken's commit only fixed proc time.
Would you please refer to my previous comment to take a look at my eventtime usecase. thanks a lot!
------update
i found the correct timestamp was changed in OutputRowtimeProcessFunction, using SqlFunctions.internalToTimestamp(), i'm not sure whether its redundant or not.
please fix this problem. thx

walterddr · 2018-12-12T04:24:35Z

@walterddr could you please check the timezone problem when dealing with eventtime?
it seems that lamber-ken's commit only fixed proc time.
Would you please refer to my previous comment to take a look at my eventtime usecase. thanks a lot!
------update
i found the correct timestamp was changed in OutputRowtimeProcessFunction, using SqlFunctions.internalToTimestamp(), i'm not sure whether its redundant or not.
please fix this problem. thx

FLINK-11010 only reports bugs for utilizing currentProcessingTime(). maybe we can mark the JIRA as duplicate of FLINK-8353 and focus on addressing the bigger overall timezone problem instead. what do you think?

hequn8128

@lamber-ken Thanks for looking into the problem and bring the discussions.
I'm afraid we can't add the offset simply. I have answered your question in the user mailing list. Below is a copy:

The two methods(add offset and minus offset) do not have to appear in pairs. Currently, Flink doesn't support time zone configuration. The timestamp(time of type Timestamp) always means the time in UTC+0. So in the test of your pr[1], the output timestamp means a time in UTC+0, instead of a time in your timezone. You can verify it by changing your sql to:
String sqlQuery = "select proctime, LOCALTIMESTAMP from MyTable";

But you raised a good question and it is true that it would be better to support time zone configuration in Flink. For example, provide a global timezone configuration. However, it is not a one or two lines code change. We need to take all operators into consideration. And it is better to solve it once for all.

Best, Hequn

flink-libraries/flink-table/src/main/scala/org/apache/flink/table/codegen/CodeGenerator.scala

lamberken · 2018-12-29T03:46:09Z

hi, @hequn8128, tableEnv can set timezone like bellow code. but just only set the timezone, not apply to flink system. yes, it is better to solve it once for all, not just add the offset simply.

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tableEnv = StreamTableEnvironment.getTableEnvironment(env);
tableEnv.getConfig().setTimeZone(TimeZone.getDefault());

Or it can just add the offset simply now, and then redesign how to solve this problem(for example, a global timezone configuration). because it can solve the problem currently.

hequn8128 · 2018-12-30T12:07:39Z

@lamber-ken Yes, you are right. It would be good if we can solve it in a simple way. However, you pr would bring some side effects.

Basically, Flink returns timestamp in UTC+0. With your pr, the output time is a local timestamp for proctime. However, you only changed one place about how to represent a timestamp. There are a lot of other places still return timestamp in UTC+0 which would bring confusion and inconsistency.

Flink also returns and only returns local timestamp in functions that clearly indicate that the time of the return type is a local timestamp, such as the CURRENT_TIMESTAMP function. String sqlQuery = "select proctime, LOCALTIMESTAMP from MyTable"; This is why offset is added in the place of the link you have provided.

Best, Hequn

lamberken · 2018-12-30T13:04:49Z

@hequn8128, Ok, I see. thanks

wangxlong · 2019-01-10T15:04:58Z

Besides the 'select proctime' case, windowStart and windowEnd fields also have this problem when using processing-time window.

if (windowStartOffset.isDefined) {
      output.setField(
        lastFieldPos + windowStartOffset.get,
        SqlFunctions.internalToTimestamp(windowStart))
    }
if (windowEndOffset.isDefined) {
      output.setField(
        lastFieldPos + windowEndOffset.get,
        SqlFunctions.internalToTimestamp(windowEnd))
   }

[FLINK-11010] Flink SQL timestamp is inconsistent with currentProcess…

5c201f2

…ingTime()

walterddr reviewed Dec 2, 2018

View reviewed changes

add sql proctime test

19d8f62

modify sql proctime test, use context.currentProcessingTime

50d1cc9

trigger rebuild

1e6761e

walterddr reviewed Dec 11, 2018

View reviewed changes

lamberken added 2 commits December 11, 2018 14:38

modify sql proctime test, just validate hour

c7ab018

trigger rebuild

575f297

trigger rebuild

1f34b74

hequn8128 reviewed Dec 29, 2018

View reviewed changes

flink-libraries/flink-table/src/main/scala/org/apache/flink/table/codegen/CodeGenerator.scala Show resolved Hide resolved

rmetzger added the component=API/TableSQL label Mar 18, 2019

lamberken closed this May 16, 2019

rmetzger added component=TableSQL/API and removed component=API/TableSQL labels May 16, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FLINK-11010] [TABLE] Flink SQL timestamp is inconsistent with currentProcessingTime() #7180

[FLINK-11010] [TABLE] Flink SQL timestamp is inconsistent with currentProcessingTime() #7180

lamberken commented Nov 27, 2018

lamberken commented Nov 27, 2018 •

edited

walterddr left a comment

lamberken commented Dec 2, 2018

walterddr commented Dec 2, 2018 •

edited

lamberken commented Dec 4, 2018 •

edited

lamberken commented Dec 4, 2018 •

edited

lzqdename commented Dec 6, 2018 •

edited

lamberken commented Dec 6, 2018

Jennifer-sarah commented Dec 7, 2018

walterddr commented Dec 7, 2018

lamberken commented Dec 7, 2018

lzqdename commented Dec 10, 2018 •

edited

lamberken commented Dec 10, 2018 •

edited

AdolphKK commented Dec 10, 2018

samsai commented Dec 11, 2018

lamberken commented Dec 11, 2018

walterddr left a comment

walterddr Dec 11, 2018

lamberken Dec 11, 2018

lamberken commented Dec 11, 2018 •

edited

samsai commented Dec 12, 2018 •

edited

walterddr commented Dec 12, 2018

hequn8128 left a comment •

edited

lamberken commented Dec 29, 2018

hequn8128 commented Dec 30, 2018 •

edited

lamberken commented Dec 30, 2018

wangxlong commented Jan 10, 2019 •

edited

[FLINK-11010] [TABLE] Flink SQL timestamp is inconsistent with currentProcessingTime() #7180

[FLINK-11010] [TABLE] Flink SQL timestamp is inconsistent with currentProcessingTime() #7180

Conversation

lamberken commented Nov 27, 2018

What is the purpose of the change

Brief change log

Does this pull request potentially affect one of the following parts:

Documentation

lamberken commented Nov 27, 2018 • edited

minimal reproducible example

result

walterddr left a comment

Choose a reason for hiding this comment

lamberken commented Dec 2, 2018

walterddr commented Dec 2, 2018 • edited

lamberken commented Dec 4, 2018 • edited

lamberken commented Dec 4, 2018 • edited

lzqdename commented Dec 6, 2018 • edited

the minus value is 28800000, ---> 8 hours ,because I am in China.

lamberken commented Dec 6, 2018

Jennifer-sarah commented Dec 7, 2018

walterddr commented Dec 7, 2018

lamberken commented Dec 7, 2018

lzqdename commented Dec 10, 2018 • edited

lamberken commented Dec 10, 2018 • edited

AdolphKK commented Dec 10, 2018

samsai commented Dec 11, 2018

lamberken commented Dec 11, 2018

walterddr left a comment

Choose a reason for hiding this comment

walterddr Dec 11, 2018

Choose a reason for hiding this comment

lamberken Dec 11, 2018

Choose a reason for hiding this comment

lamberken commented Dec 11, 2018 • edited

samsai commented Dec 12, 2018 • edited

walterddr commented Dec 12, 2018

hequn8128 left a comment • edited

Choose a reason for hiding this comment

lamberken commented Dec 29, 2018

hequn8128 commented Dec 30, 2018 • edited

lamberken commented Dec 30, 2018

wangxlong commented Jan 10, 2019 • edited

lamberken commented Nov 27, 2018 •

edited

walterddr commented Dec 2, 2018 •

edited

lamberken commented Dec 4, 2018 •

edited

lamberken commented Dec 4, 2018 •

edited

lzqdename commented Dec 6, 2018 •

edited

lzqdename commented Dec 10, 2018 •

edited

lamberken commented Dec 10, 2018 •

edited

lamberken commented Dec 11, 2018 •

edited

samsai commented Dec 12, 2018 •

edited

hequn8128 left a comment •

edited

hequn8128 commented Dec 30, 2018 •

edited

wangxlong commented Jan 10, 2019 •

edited