I'm using Infopath Designer 2013.
I need to create a unique ID of YYMMDDHHMMSS , with no symbols.
I have used "concat(Request Type, TodayYear(substring(now(), 1, 4)), TodayMonth(substring(now(), 6, 2)), TodayDate(substring(now(), 9, 2)), TodayHour(substring(now(), 12, 5)), TodayMinute, TodaySecond)"
However i cannot get the TodayMinute to display just MM and TodaySecond to display just SS with no symbols i.e. ":".
Can anyone help with this?
Found a work around
Year - substring(now(), 1, 4) - 1st letter return 4
Month - substring(now(), 6, 2) - 6th letter return 2
Date - substring(now(), 9, 2) - 9th letter return 2
Hour - substring(now(), 12, 2) - 12th letter return 2
Minute - substring(now(), 15, 2) - 15th letter return 2
Second - substring(now(), 18, 2) - 18th letter return 2
Related
I am working in R, this is a look of my table :
IAE_2017 IAE_2018
L1PYSH L2PYSH
M1CHIMIE M2CHIMIE
..... ........
Now I want to make a condition which take the 2 first caracters of IAE_2017 and verify if it is different for the 2 fisrt's of IAE_2018.
You could use substr(), assuming df a dataframe :
substr(df[,1], start = 1, stop = 2)==substr(df[,2], start = 1, stop = 2)
As we all know, date parsing in Go has it's quirks*.
However, I have now come up against needing to parse a datetime string in CCYY-MM-DDThh:mm:ss[.sss...] to a valid date in Go.
This CCYY format is a format that seems to be ubiquitous in astronomy, essentially the CC is the current century, so although we're in 2022, the century is the 21st century, meaning the date in CCYY format would be 2122.
How do I parse a date string in this format, when we can't specify a coded layout?
Should I just parse in that format, and subtract one "century" e.g., 2106 becomes 2006 in the parsed datetime...?
Has anyone come up against this niche problem before?
*(I for one would never have been able to remember January 2nd, 3:04:05 PM of 2006, UTC-0700 if it wasn't the exact time of my birth! I got lucky)
The time package does not support parsing centuries. You have to handle it yourself.
Also note that a simple subtraction is not enough, as e.g. the 21st century takes place between January 1, 2001 and December 31, 2100 (the year may start with 20 or 21). If the year ends with 00, you do not have to subtract 100 years.
I would write a helper function to parse such dates:
func parse(s string) (t time.Time, err error) {
t, err = time.Parse("2006-01-02T15:04:05[.000]", s)
if err == nil && t.Year()%100 != 0 {
t = t.AddDate(-100, 0, 0)
}
return
}
Testing it:
fmt.Println(parse("2101-12-31T12:13:14[.123]"))
fmt.Println(parse("2122-10-29T12:13:14[.123]"))
fmt.Println(parse("2100-12-31T12:13:14[.123]"))
fmt.Println(parse("2201-12-31T12:13:14[.123]"))
Which outputs (try it on the Go Playground):
2001-12-31 12:13:14.123 +0000 UTC <nil>
2022-10-29 12:13:14.123 +0000 UTC <nil>
2100-12-31 12:13:14.123 +0000 UTC <nil>
2101-12-31 12:13:14.123 +0000 UTC <nil>
As for remembering the layout's time:
January 2, 15:04:05, 2006 (zone: -0700) is a common order in the US, and in this representation parts are in increasing numerical order: January is month 1, 15 hour is 3PM, year 2006 is 6. So the ordinals are 1, 2, 3, 4, 5, 6, 7.
I for one would never have been able to remember January 2nd, 3:04:05 PM of 2006, UTC-0700 if it wasn't the exact time of my birth! I got lucky.
The reason for the Go time package layout is that it is derived from the Unix (and Unix-like) date command format. For example, on Linux,
$ date
Fri Apr 15 08:20:43 AM EDT 2022
$
Now, count from left to right,
Month = 1
Day = 2
Hour = 3 (or 15 = 12 + 3)
Minute = 4
Second = 5
Year = 6
Note: Rob Pike is an author of The Unix Programming Environment
I'm working to fill an array with High/Low pivot points of the "Previous Trading Day", but I'm facing an issue in terms of the time series (second section below!). I'm not sure if that PineScript's bug or my misunderstanding of how are the time-series functions working!! Please Help, very organize details.
Calling for current Trading Day, then selected the regular session ( No issues in this part )
//------------------ Selected Day of Trading
//Start Day
Start_Period= timestamp(syminfo.timezone, 2020, 12, 09, 00, 00, 00)
//End Day
End_Period = timestamp(syminfo.timezone, 2020, 12, 09, 23, 59, 59)
//------------------ Filtring Session
// Regular Session
t_reg = time("1440", session.regular)
The issue only in this coding box.
Pine script would not recognize the result of Change_Time
// Detect the change of time between selected day trading and most recent day trading (t-t[1])
Change_Time = security(syminfo.tickerid, "1440", change(time))
FunYesterday()=>
if time >= Start_Period-Change_Time and time <= End_Period-Change_Time and t_reg
[pivothigh(close, 3, 2), pivotlow(close, 3, 2)]
However, if I substitute the security function of Change_time= 60*60*24*1000will work fine!!, but I tried to avoid this method because of time deference on weekends, and other holidays.
Final Section find Pivot and Create Array ( No issues in this part )
//------------------ Pivot point at 15 min.
[ph2, pl2] = security(syminfo.tickerid, "15", FunYesterday(), lookahead = barmerge.lookahead_off)
ph2_filter= ph2 == ph2[1]?na:ph2
pl2_filter= pl2 == pl2[1]?na:pl2
//------------------ Array Part
var a = array.new_float()
if (not na(ph2_filter))
array.push(a,ph2_filter)
else if (not na(pl2_filter))
array.push(a,pl2_filter)
if barstate.islast and array.size(a)>0
y=label.new(bar_index, close, "Initial\na: " + tostring(a))
label.delete(y[1])
I'm very open if you have any other idea to import data from the most recent trading day only!!. Thank you
I'm running into an issue when I'm trying to create a histogram of specific createdAt datetimes for orders. The issue is that even after created timezone aware datetimes, the .weekday() shows up as the same day, even though it should be a different time
The code I'm using to test this occurrence is as follows:
import datetime
import pytz
value = {
'createdAt': '2017-04-24T00:48:03+00:00'
}
created_at = datetime.datetime.strptime(value['createdAt'], '%Y-%m-%dT%H:%M:%S+00:00')
timezone = pytz.timezone('America/Los_Angeles')
created_at_naive = created_at
created_at_aware = timezone.localize(created_at_naive)
print(created_at_naive) # 2017-04-24 00:48:03
print(created_at_aware) # 2017-04-24 00:48:03-07:00
print(created_at_naive.weekday()) # 0 (Monday)
print(created_at_aware.weekday()) # 0 (should be Sunday)
The problem is that you need to actually change the datetime to the new timezone:
>>> timezone('UTC').localize(created_at)
datetime.datetime(2017, 4, 24, 0, 48, 3, tzinfo=<UTC>)
>>>timezone('UTC').localize(created_at).astimezone(timezone('America/Los_Angeles'))
datetime.datetime(2017, 4, 23, 17, 48, 3, tzinfo=<DstTzInfo 'America/Los_Angeles' PDT-1 day, 17:00:00 DST>)
Flex is driving me CRAZY and I think it's some weird gotcha with how it handles leap years and none leap years. So here's my example. I have the below dateDiff method that finds the number of days or milliseconds between two dates. If I run the following three statements I get some weird issues.
dateDiff("date", new Date(2010, 0,1), new Date(2010, 0, 31));
dateDiff("date", new Date(2010, 1,1), new Date(2010, 1, 28));
dateDiff("date", new Date(2010, 2,1), new Date(2010, 2, 31));
dateDiff("date", new Date(2010, 3,1), new Date(2010, 3, 30));
If you were to look at the date comparisons above you would expect to get 30, 27, 30, 29 as the number of days between the dates. There weird part is that I get 29 when comparing March 1 to March 31. Why is that? Is it something to do with February only having 28 days? If anyone has ANY input on this that would be greatly appreciated.
public static function dateDiff( datePart:String, startDate:Date, endDate:Date ):Number
{
var _returnValue:Number = 0;
switch (datePart) {
case "milliseconds":
_returnValue = endDate.time - startDate.time;
break;
case "date":
// TODO: Need to figure out DST problem i.e. 23 hours at DST start, 25 at end.
// Math.floor causes rounding down error with DST start at dayOfYear
_returnValue = Math.floor(dateDiff("milliseconds", startDate, endDate)/(1000 * 60 * 60 * 24));
break;
}
return _returnValue;
}
This is not a leap year problem, but rather a daylight savings time problem.
To correct the code to account for DST, you need to look at the timezoneOffset of both dates to determine if the date range is spanning a DST boundary.
var adjustment:Number = ( startDate.timezoneOffset - endDate.timezoneOffset ) * 60 * 1000;
_returnValue = endDate.time - startDate.time + adjustment;
This will get the difference between the two time zones (in minutes), convert that value to milliseconds, and then apply the timezone difference to the millisecond difference to "cancel out" the DST boundary.
Naturally, when both numbers are in the same time zone, the adjustment value becomes 0 and the time values are not adjusted.
You have part of the answer in your comment: 2010-Mar-01 0:00 until 2010-Mar-31 0:00 is thirty (!) days minus one hour (because Mar 14 is DST start in 2010). Since you floor the result of your division, you get 29.
Edit: This answer is of course based on the assumption that the time property of Date takes DST into account. This would explain your problem; I didn't check it, however.