LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mrbigglesdotnet

Hi there,

On my version of Lavastorm, when I use the time() function to extract the time from a datetime column, the output always has 30 minutes added to it.

Is there a setting I need to change?

or

Is how do I take the output that is +30 minutes and subtract 30 minutes from that output?

Here are the example nodes:

node:DateTime_Sample
bretype:core::Static Data
editor:Label=Date/Time Sample
editor:sortkey=536cbf597acb3345
output:@40fe6c55598828e5/=
prop:StaticData=<<EOX
datetime:datetime
2014-3-14 10:00:23
2014-3-8 9:56:11
EOX
editor:XY=210,170
end:DateTime_Sample

node:Filter
bretype:core::Filter
editor:sortkey=54a38fe16dc3519c
input:@40fd2c74167f1ca2/=DateTime_Sample.40fe6c55598828e5
output:@40fd2c7420761db6/=
prop:Script=<<EOX
emit *
emit date(datetime) as "date"
emit time(datetime) as "time"

EOX
editor:XY=290,170
end:Filter

Attached is a screenshot of the output in case when you run the above nodes, you don't get this +30 minutes output.

time_error.jpg

Thanks.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: stonysmith

When you say that the resulting time has 30 minutes added to it, are you aware that the timezone setting on your local computer affects how the BRDViewer displays the time?

The BRD Viewer does not display the "raw" data in the file, but rather it attempts to display the time in your local timezone. If your computer happens to be set to one of the 30 minute-offset TZs, then this could account for what you are seeing.

As a quick check, try this:

emit str(date(datetime)) as "date"
emit str(time(datetime)) as "time"

and see if you notice different results.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mrbigglesdotnet

I've tried the script but am still gettting the same results (i.e. the +30 minutes from the original timestamp). I think the BRD Viewer is the issue as my Lavastorm server is in a different city which is +30 minutes to my BRE.

Is there some way to extract just the time from a datetime format? I've tried the below but am getting errors...

q=datetime.right(8)
if isTime(q,"H:MM:SS") then t=time(q,"H:MM:SS") else t = date(null)
emit *, date(datetime) as "date", time(datetime) as "time", right_time = t

... has error...

WARN: Expect string or unicode argument
Line 1; BrainScript: q=datetime.right(8)
Operator: 'right'
Error Code: brain.node.Right_ExprOp.cpp.72

ERROR: Node execution terminated while processing data by error:
Expect string or unicode argument
Error Code: lae.node.executionTermindated

and...

q=str(datetime.right(8))
if isTime(q,"H:MM:SS") then t=time(q,"H:MM:SS") else t = date(null)
emit *, date(datetime) as "date", time(datetime) as "time", right_time = t

... has error...

WARN: Expect string or unicode argument
Line 1; BrainScript: q=str(datetime.right(8))
Operator: 'right'
Error Code: brain.node.Right_ExprOp.cpp.72

ERROR: Node execution terminated while processing data by error:
Expect string or unicode argument
Error Code: lae.node.executionTermindated

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: ejones

You were extracting the date and time part correctly in your first question, where you have date(datetime) and time(datetime)

So, what you are asking doesn't seem to me to be going in the correct direction since your original direction was correct for the timezone the server is located in. And as the error message indicates, you cannot apply a string fuction of right() to the datetime value because the function only works on strings.

I believe this makes the syntax of what you are attempting to do work. It converts the datetime to a string in the assumed format and then as a string you can operate on it with the right() function:
q=datetime.str().right(8)

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mrbigglesdotnet

Thanks for the attempt, however I'm still getting the same error. I've tried...

q=datetime.str().right(8)
if isTime(q,"H:MM:SS") then t=time(q,"H:MM:SS") else t = time(null)
emit *, date(datetime) as "date", time(datetime) as "time", right_time = t

and am getting...

time_error2.jpg

and have also tried...

emit *, datetime.str() as "datetimestring"

with the same +30 minute result...

time_error3.jpg

Is there anyway to resolve this at all?

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: ejones

So, where you are seeing differences, I am seeing consistency. (granted, it is not easy to see this consistency) The solution is for you to change your windows client session to be in the same timezone as your LAE server. This won't change anything but will make things look consistent. Here is why:

You said that the LAE server is 30 minutes ahead of your local time on your client machine.
First Example:
1. A Static Data node runs on the LAE server converting a string value to a datetime on the LAE server.
2. A filter node extracts the date and time parts.
- Note that the datetime value includes the timezone information but the date and time values do not.
3. You display the output of the filter node which has the date and time fields plus the original datetime value. This runs on the LAE server in its timezone.
- Note that the date and time values show exactly the contents of the static data node so this is why I say it worked. Since these date and time values do not carry any timezone information the BRD viewer displays them as you expect. So they show the same numbers in whatever timezone you are in even though those numbers would be a different time in other timezones.
- AND note that the display in the BRD viewer of the datetime value is shown as 30 minutes earlier because the datetime value includes timezone information. The timezone on your client machine is 30 minutes before the LAE server's time.
- It is consistent for the first record because at 9:30 on your client machine it will be 10:00 on the server. Since the datetime value contains the timezone it contains enough information so that it can represent the same instant of time in all timezones.

Last Example with 'emit *, datetime.str() as "datetimestring"':
1. The data from same static data node gets converted on the LAE server to the datetime.
2. Inside the emit the data in the datetime value gets converted back to a string and written as datetimestring in the LAE server's timezone.
3. You display this result on your client BRE session.
- The datetimestring represents the same value that is in the original static data node.
- The datetime value displays a time 30 minutes before the time in the static data node. Note that this is the time in your local timezone that represents the time in the static data node where when you look at a clock in the LAE server's timezone it will match. At 9:30 on your client it will be 10:00 on the server.

So:
To see what you expect to see you need to change the timezone used by the BRD viewer to display datetime values. The way to do this is to change the whole machine to be in the same timezone as the LAE server. This is what I have been doing. Since the LAE server is 1 hour ahead and also in the timezone of the home office for the company I work for, a lot of things work out nice doing this when I coordinate with other people at work. But it is difficult and confusing to make plans with my wife who is in my local timezone while the time on my laptop is 1 hour ahead. And as soon as my wife finds out about this she notes it as evidence I'm putting my work ahead of her, yikes!!

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mrbigglesdotnet

Thanks for the super clear explanation. It makes sense and I can see why it's been programmed that way to ensure data integrity. I've change the time zone of my client to match the LAE server and hey presto, no more different time values. Thanks again!