Downloading...
Download

Timesessions

BoxLine_LibLibrary "BoxLine_Lib" personal Library for line and box built in functions lineXY(x)    get x1,y1,x2,y2 in a tuple   Parameters:      x : TODO: line   Returns: tuple of x1,y1,x2,y2 line(x)   Create line with only the y1 value(when line == na) or all when line != na set x1,y1,x2,y2 individually just 1 or all - use just the line value to set the x2 to current bar or time will set to time - will auto pick xloc.bar_index or xloc.bar_time if not used   Parameters:      x : (line line,int x1,float y1,int x2,float y2, string xloc,string extend,color color,string style,int width)   Returns: Line boxXY(x)    get left,top,right,bottom in a tuple   Parameters:      x : box   Returns: tuple of left,top,right,bottom box(x)   Create line with only the top,bottom value(when line == na) or all when box != na set left,top,right,bottom individually just 1 or all - use just the box value to set the right to current bar or time will set to time - if right is above a number that a bar_index wouldnt be   Parameters:      x : box box,int left,float top,int right, float bottom,color border_color, int border_width, string border_style,string extend,string xloc, color bgcolor,string text,string text_size, color text_color, string text_halign,string text_valign,string text_wrap)   Returns: TODO: Box
Pine Script® library
by FFriZz
2
LibBacktestingDayRangeLibrary "LibBacktestingDayRange" TODO: add library description here import Nut_Satit/CalulateWinLoss/version as backtest rangdate(startDate, finishDate)   TODO: add function description here   Parameters:      startDate : TODO: add parameter startDate description here finishDate : TODO: add parameter finishDate description here   Returns: TODO: add what function returns time_cond : TODO: insert variable and buy or sell condition
Pine Script® library
by Nut_Satit
SAT_LIBLibrary "SAT_LIB" TODO: This library regroups indicator's functions and functions i use a lot getRENKOLEVELS(upColor1, dnColor1, HIGH, LOW, ATR)   TODO: RenkoLevels indicator by Mongolor function   Parameters:      upColor1 : TODO: (Type: color) renko up color      dnColor1 : TODO: (Type: color) renko down color      HIGH : TODO: (Type: float)      LOW : TODO: (Type: float)      ATR : TODO: (Type: float)   Returns: TODO: Renkolevels
Pine Script® library
by sosso_bott
6
DateNow█ OVERVIEW Library "DateNow" TODO: Provide today's date based on UNIX time █ INSPIRATIONS Use pinescript v4 functions such as year(), month() and dayofmonth(). Use pinescript v5 function such as switch. Export as string variables. Not using any match function such as math.floor. █ CREDITS RicardoSantos █ KNOWN ISSUES Date for Day display incorrectly by shortage 1 value especially Year equal to or before 1984 Timezone issue. Example : I using GMT+8 for my timezone, try using other GMT will not work. Al least, GMT+2 to GMT+13 is working. GMT-0 to GMT+1 is not working, although already attempt using UTC-10 to UTC-1. dateNow()   : DateNow   Parameters:      : : _timezone   Returns: : YYYY, YY, M, MM, MMM, DD
Pine Script® library
by RozaniGhani-RG
PriceTimeInteractive█ OVERVIEW This library was intended to Get price of given time.input █ CREDITS Credits to TradingView for CAGR Custom Range. █ FUNCTIONS ohlc_time()   : Get OHLC price of given time.input   Parameters:      : : Time (t) must be using time.input   Returns: : OHLC hlc_time()   : Get HLC price of given time.input   Parameters:      : : Time (t) must be using time.input   Returns: : HLC hl_time()   : Get HL price of given time.input   Parameters:      : : Time (t) must be using time.input   Returns: : HL
Pine Script® library
by RozaniGhani-RG
2
Time█   OVERVIEW This library is a Pine Script™ programmer’s tool containing a variety of time related functions to calculate or measure time, or format time into string variables. █   CONCEPTS `formattedTime()`, `formattedDate()` and `formattedDay()` Pine Script™, like many other programming languages, uses timestamps in UNIX format, expressed as the number of milliseconds elapsed since 00:00:00 UTC, 1 January 1970. These three functions convert a UNIX timestamp to a formatted string for human consumption. These are examples of ways you can call the functions, and the ensuing results: CODE RESULT formattedTime(timenow) >>> "00:40:35" formattedTime(timenow, "short") >>> "12:40 AM" formattedTime(timenow, "full") >>> "12:40:35 AM ​UTC​" formattedTime(1000 * 60 * 60 * 3.5, "HH:mm") >>> "03:30" formattedDate(timenow, "short") >>> "4/30/22" formattedDate(timenow, "medium") >>> ​"Apr​ 30, 2022" formattedDate(timenow, "full") >>> "Saturday, April 30, 2022" formattedDay(timenow, "E") >>> "Sat" formattedDay(timenow, "dd.MM.yy") >>> "30.04.22" formattedDay(timenow, "yyyy.MM.dd G 'at' hh:mm:ss z") >>> "2022.04.30 AD at 12:40:35 UTC" These functions use str.format() and some of the special formatting codes it allows for. Pine Script™ documentation does not yet contain complete specifications on these codes, but in the meantime you can find some information in the The Java™ Tutorials and in Java documentation of its MessageFormat class . Note that str.format() implements only a subset of the MessageFormat features in Java. `secondsSince()` The introduction of varip variables in Pine Script™ has made it possible to track the time for which a condition is true when a script is executing on a realtime bar. One obvious use case that comes to mind is to enable trades to exit only when the exit condition has been true for a period of time, whether that period is shorter that the chart's timeframe, or spans across multiple realtime bars. For more information on this function and varip please see our Using `varip` variables publication. `timeFrom( )` When plotting lines , boxes , and labels one often needs to calculate an offset for past or future end points relative to the time a condition or point occurs in history. Using xloc.bar_index is often the easiest solution, but some situations require the use of xloc.bar_time . We introduce `timeFrom()` to assist in calculating time-based offsets. The function calculates a timestamp using a negative (into the past) or positive (into the future) offset from the current bar's starting or closing time, or from the current time of day. The offset can be expressed in units of chart timeframe, or in seconds, minutes, hours, days, months or years. This function was ported from our Time Offset Calculation Framework . `formattedNoOfPeriods()` and `secondsToTfString()` Our final two offerings aim to confront two remaining issues: How much time is represented in a given timestamp? How can I produce a "simple string" timeframe usable with request.security() from a timeframe expressed in seconds? `formattedNoOfPeriods()` converts a time value in ​ms to a quantity of time units. This is useful for calculating a difference in time between 2 points and converting to a desired number of units of time. If no unit is supplied, the function automatically chooses a unit based on a predetermined time step. `secondsToTfString()` converts an input time in seconds to a target timeframe string in timeframe.period string format. This is useful for implementing stepped timeframes relative to the chart time, or calculating multiples of a given chart timeframe. Results from this function are in simple form, which means they are useable as `timeframe` arguments in functions like request.security() . █   NOTES Although the example code is commented in detail, the size of the library justifies some further explanation as many concepts are demonstrated. Key points are as follows:  • ​Pivot points are used to draw lines from. `timeFrom( )` calculates the length of the lines in the specified unit of time.   By default the script uses 20 units of the charts timeframe. Example: a 1hr chart has arrows 20 hours in length.  • At the point of the arrows `formattedNoOfPeriods()` calculates the line length in the specified unit of time from the input menu.   If “Use Input Time” is disabled, a unit of time is automatically assigned.  • At each ​pivot point a label with a formatted date or time is placed with one of the three formatting helper functions to display the time or date the ​pivot occurred.  • A label on the last bar showcases `secondsSince()` . The label goes through three stages of detection for a timed alert.   If the difference between the high and the open in ticks exceeds the input value, a timer starts and will turn the label red once the input time is exceeded to simulate a time-delayed alert.  • In the bottom right of the screen `secondsToTfString()` posts the chart timeframe in a table. This can be multiplied from the input menu. Look first. Then leap. █   FUNCTIONS formattedTime(timeInMs, format)   Converts a UNIX timestamp (in milliseconds) to a formatted time string.   Parameters:      timeInMs : (series float) Timestamp to be formatted.      format : (series string) Format for the time. Optional. The default value is "HH:mm:ss".   Returns: (string) A string containing the formatted time. formattedDate(timeInMs, format)   Converts a UNIX timestamp (in milliseconds) to a formatted date string.   Parameters:      timeInMs : (series float) Timestamp to be formatted.      format : (series string) Format for the date. Optional. The default value is "yyyy-MM-dd".   Returns: (string) A string containing the formatted date. formattedDay(timeInMs, format)   Converts a UNIX timestamp (in milliseconds) to the name of the day of the week.   Parameters:      timeInMs : (series float) Timestamp to be formatted.      format : (series string) Format for the day of the week. Optional. The default value is "EEEE" (complete day name).   Returns: (string) A string containing the day of the week. secondsSince(cond, resetCond)   The duration in milliseconds that a condition has been true.   Parameters:      cond : (series bool) Condition to time.      resetCond : (series bool) When `true`, the duration resets.   Returns: The duration in seconds for which `cond` is continuously true. timeFrom(from, qty, units)   Calculates a +/- time offset in variable units from the current bar's time or from the current time.   Parameters:      from : (series string) Starting time from where the offset is calculated: "bar" to start from the bar's starting time, "close" to start from the bar's closing time, "now" to start from the current time.      qty : (series int) The +/- qty of units of offset required. A "series float" can be used but it will be cast to a "series int".      units : (series string) String containing one of the seven allowed time units: "chart" (chart's timeframe), "seconds", "minutes", "hours", "days", "months", "years".   Returns: (int) The resultant time offset `from` the `qty` of time in the specified `units`. formattedNoOfPeriods(​ms, unit)   Converts a time value in ​ms to a quantity of time units.   Parameters:      ms : (series int) Value of time to be formatted.      unit : (series string) The target unit of time measurement. Options are "seconds", "minutes", "hours", "days", "weeks", "months". If not used one will be automatically assigned.   Returns: (string) A formatted string from the number of `ms` in the specified `unit` of time measurement secondsToTfString(tfInSeconds, mult)   Convert an input time in seconds to target string TF in `timeframe.period` string format.   Parameters:      tfInSeconds : (simple int) a timeframe in seconds to convert to a string.      mult : (simple float) Multiple of `tfInSeconds` to be calculated. Optional. 1 (no multiplier) is default.   Returns: (string) The `tfInSeconds` in `timeframe.period` format usable with `request.security()`.
Pine Script® library
by PineCoders
35
HighTimeframeTimingLibrary "HighTimeframeTiming" @description Library for sampling high timeframe (HTF) historical data at an arbitrary number of HTF bars back, using a single security() call. The data is fixed and does not alter over the course of the HTF bar. It also behaves consistently on historical and elapsed realtime bars. ‼ LIMITATIONS: This library function depends on there being a consistent number of chart timeframe bars within the HTF bar. This is almost always true in 24/7 markets like crypto. This might not be true if the chart doesn't produce an update when expected, for example because the asset is thinly traded and there is no volume or price update from the feed at that time. To mitigate this risk, use this function on liquid assets and at chart timeframes high enough to reliably produce updates at least once per bar period. The consistent ratio of bars might also break down in markets with irregular sessions and hours. I'm not sure if or how one could mitigate this. Another limitation is that because we're accessing a multiplied number of chart bars, you will run out of chart bars faster than you would HTF bars. This is only a problem if you use a large historical operator. If you call a function from this library, you should probably reproduce these limitations in your script description. However, all of this doesn't mean that this function might not still be the best available solution, depending what your needs are. If a single chart bar is skipped, for example, the calculation will be off by 1 until the next HTF bar opens. This is certainly inconsistent, but potentially still usable. @function f_offset_synch(float _HTF_X, int _HTF_H, int _openChartBarsIn, bool _updateEarly) Returns the number of chart bars that you need to go back in order to get a stable HTF value from a given number of HTF bars ago. @param float _HTF_X is the timeframe multiplier, i.e. how much bigger the selected timeframe is than the chart timeframe. The script shows a way to calculate this using another of my libraries without using up a security() call. @param int _HTF_H is the historical operator on the HTF, i.e. how many bars back you want to go on the higher timeframe. If omitted, defaults to zero. @param int _openChartBarsIn is how many chart bars have been opened within the current HTF bar. An example of calculating this is given below. @param bool _updateEarly defines whether you want to update the value at the closing calculation of the last chart bar in the HTF bar or at the open of the first one. @returns an integer that you can use as a historical operator to retrieve the value for the appropriate HTF bar. 🙏 Credits: This library is an attempt at a solution of the problems in using HTF data that were laid out by Pinecoders in "security() revisited" - Thanks are due to the authors of that work for an understanding of HTF issues. In addition, the current script also includes some of its code. Specifically, this script reuses the main function recommended in "security() revisited", for the purposes of comparison. And it extends that function to access historical data, again just for comparison. All the rest of the code, and in particular all of the code in the exported function, is my own. Special thanks to LucF for pointing out the limitations of my approach. ~~~~~~~~~~~~~~~~| EXPLANATION ~~~~~~~~~~~~~~~~| Problems with live HTF data: Many problems with using live HTF data from security() have been clearly explained by Pinecoders in "security() revisited" In short, its behaviour is inconsistent between historical and elapsed realtime bars, and it changes in realtime, which can cause calculations and alerts to misbehave. Various unsatisfactory solutions are discussed in "security() revisited", and understanding that script is a prerequisite to understanding this library. PineCoders give their own solution, which is to fix the data by essentially using the previous HTF bar's data. Importantly, that solution is consistent between historical and realtime bars. This library is an attempt to provide an alternative to that solution. Problems with historical HTF data: In addition to the problems with live HTF data, there are different issues when trying to access historical HTF data. Why use historical HTF data? Maybe you want to do custom calculations that involve previous HTF bars. Or to use HTF data in a function that has mutable variables and so can't be done in a security() call. Most obviously, using the historical operator (in this description, represented using { } because the square brackets don't render) on variables already retrieved from a security() call, e.g. HTF_Close{1}, is not very useful: it retrieves the value from the previous *chart* bar, not the previous HTF bar. Using {1} directly in the security() call instead does get data from the previous HTF bar, but it behaves inconsistently, as we shall see. This library addresses these concerns as well. Housekeeping: To follow what's going on with the example and comparisons, turn line labels on: Settings > Scales > Indicator Name Label. The following explanation assumes "close" as the source, but you can change it if you want. To quickly see the difference between historical and realtime bars, set the HTF to something like 3 minutes on a 15s chart. The bars at the top of the screen show the status. Historical bars are grey, elapsed realtime bars are red, and the realtime bar is green. A white vertical line shows the open of a HTF bar. A: This library function f_offset_synch(): When supplied with an input offset of 0, it plots a stable value of the close of the *previous* HTF bar. This value is thus safe to use for calculations and alerts. For a historical operator of {1}, it gives the close of the *last-but-one* bar. Sounds simple enough. Let's look at the other options to see its advantages. B: Live HTF data: Represented on the line label as "security(){0}". Note: this is the source that f_offset_synch() samples. The raw HTF data is very different on historical and realtime bars: + On historical bars, it uses a flat value from the end of the previous HTF bar. It updates at the close of the HTF bar. + On realtime bars, it varies between and within each chart bar. There might be occasions where you want to use live data, in full knowledge of its drawbacks described above. For example, to show simple live conditions that are reversible after a chart bar close. This library transforms live data to get the fixed data, thus giving you access to both live and fixed data with only one security() call. C: Historical data using security(){H}: To see how this behaves, set the {H} value in the settings to 1 and show options A, B, and C. + On historical bars, this option matches option A, this library function, exactly. It behaves just like security(){0} but one HTF bar behind, as you would expect. + On realtime bars, this option takes the value of security(){0} at the end of a HTF bar, but it takes it from the previous *chart* bar, and then persists that. The easiest way to see this inconsistency is on the first realtime bar (marked red at the top of the screen). This option suddenly jumps, even if it's in the middle of a HTF bar. Contrast this with option A, which is always constant, until it updates, once per HTF bar. D: PineCoders' original function: To see how this behaves, show options A, B, and D. Set the {H} value in the settings to 0, then 1. The PineCoders' original function (D) and extended function (E) do not have the same limitations as this library, described in the Limitations section. This option has all of the same advantages that this library function, option A, does, with the following differences: + It cannot access historical data. The {H} setting makes no difference. + It always updates at the open of the first chart bar in a new HTF bar. By contrast, this library function, option A, is configured by default to update at the close of the last chart bar in a HTF bar. This little frontrunning is only a few seconds but could be significant in trading. E.g. on a 1D HTF with a 4H chart, an alert that involves a HTF change set to trigger ON CLOSE would trigger 4 hours later using this method - but use exactly the same value. It depends on the market and timeframe as to whether you could actually trade this. E.g. at the very end of a tradfi day your order won't get executed. This behaviour mimics how security() itself updates, as is easy to see on the chart. If you don't want it, just set in_updateEarly to false. Then it matches option D exactly. E: PineCoders' function, extended to get history: To see how this behaves, show options A and E. Set the {H} value in the settings to 0, then 1. I modified the original function to be able to get historical values. In all other respects it is the same. Apart from not having the option to update earlier, the only disadvantage of this method vs this library function is that it requires one security() call for each historical operator. For example, if you wanted live data, and fixed data, and fixed data one bar back, you would need 3 security() calls. My library function requires just one. This is the essential tradeoff: extra complexity and less robustness in certain circumstances (the PineCoders function is simple and universal by comparison) for more flexibility with fewer security() calls.
Pine Script® library
by SimpleCryptoLife
7
bytimeLibrary "bytime" TODO: to do something at the specified time. ////Return =>> ht = hour , mt = minute , st = second ,Dt = Day, Mt = month, Yt = year , dateTime = full time format.///////////// Note : Remember to always add import when you call our library and change Gtime() to Timeset.Gtime() is used to access internal data. import hapharmonic/bytime/1 as Timeset =Timeset.Gtime() /////////////Set a time to trigger an alert.///////////// ck = false ///hour : minute : second if ht == TH and mt == TM and st == TS //some action //... //. ck := true Gtime()
Pine Script® library
by hapharmonic
2
TimeLockedMALibrary "TimeLockedMA" Library & function(s) which generates a moving average that stays locked to users desired time preference. TODO - Add functionality for more moving average types. IE: smooth, weighted etc... Example: time_locked_ma(close, length=1, timeframe='days', type='ema') Will generate a 1 day exponential moving average that will stay consistent across all chart intervals. Error Handling On small time frames with large moving averages (IE: 1min chart with a 50 week moving average), you'll get a study error that says "(function "sma") references too many candles in history" . To fix this, make sure you have timeframe="" as an indicator() header. Next, in the indicator settings, increase the timeframe from to a higher interval until the error goes away. By default, it's set to "Chart". Bringing the interval up to 1hr will usually solve the issue. Furthermore, adding timeframe_gaps=false to your indicator() header will give you an approximation of real-time values. Misc Info For time_lock_ma() setting type='na' will return the relative length value that adjusts dynamically to user's chart time interval. This is good for plugging into other functions where a lookback or length is required. (IE: Bollinger Bands) time_locked_ma(source, length, timeframe, type) Creates a moving average that is locked to a desired timeframe   Parameters:      source : float, Moving average source      length : int, Moving average length      timeframe : string, Desired timeframe. Use: "minutes", "hours", "days", "weeks", "months", "chart"      type : string, string Moving average type. Use "SMA" (default) or "EMA". Value of "NA" will return relative lookback length.   Returns: moving average that is locked to desired timeframe. timeframe_convert(t, a, b) Converts timeframe to desired timeframe. From a --> b   Parameters:      t : int, Time interval      a : string, Time period      b : string, Time period to convert to   Returns: Converted timeframe value chart_time(timeframe_period, timeframe_multiplier) Separates timeframe.period function and returns chart interval and period   Parameters:      timeframe_period : string, timeframe.period      timeframe_multiplier : int, timeframe.multiplier Enjoy :)
Pine Script® library
by JBroadway
2
SetSessionTimesLibrary "SetSessionTimes" Function to automatically set session times for symbols and eventually timezone. Useful mainly for futures contracts, to differentiate between pit and overnight sessions, and for 24 hours symbols if you want to "create" sessions for them This library only returns correct session times to the calling script and does nothing by itself on the chart. the calling script must then use the returned session times to do anything. For example, in the attached chart this library is used by my initial balance indicator, which calls it to retrieve the correct session times for the selected symbol in the chart, given that different futures contracts have different pit session times (RTH times) and Tradingview hasn't implemented that yet. SetSessionTimes()
Pine Script® library
by czoa
2
options_expiration_and_strike_price_calculatorLibrary "options_expiration_and_strike_price_calculator" TODO: add library description here fun() this is a library to help calculate options strike price and expiration that you can add to a script i use it mainly for symbol calulation to place orders to buy options on TD ameritrade so it will be set up to order options on TD ameritrade using json order placer and webhook it fills in the area in the json under symbol i suggest manually adding the year it should look like this is an example of an order to buy 10 call options using json through td ameritrade api "complexOrderStrategyType": "NONE", "orderType": "LIMIT", "session": "NORMAL", "price": "6.45", "duration": "DAY", "orderStrategyType": "SINGLE", "orderLegCollection": }
Pine Script® library
by natronix
4
Last Available Bar InfoLibrary "Last_Available_Bar_Info" getLastBarTimeStamp() getAvailableBars() This simple library is built with an aim of getting the last available bar information for the chart. This returns a constant value that doesn't change on bar change. For backtesting with accurate results on non standard charts, it will be helpful. (Especially if you are using non standard charts like Renko Chart). Methods getLastBarTimeStamp() : Returns Timestamp of the last available bar (Constant) getAvailableBars() :Returns Number of Available Bars on the chart (Constant) Example import paragjyoti2012/Last_Available_Bar_Info/v1 as LastBarInfo last_bar_timestamp=LastBarInfo.getLastBarTimeStamp() no_of_bars=LastBarInfo.getAvailableBars() If you are using Renko Charts, for backtesting, it's necesary to filter out the historical bars that are not of this timeframe. In Renko charts, once the available bars of the current timeframe (based on your Tradingview active plan) are exhausted, previous bars are filled in with historical bars of higher timeframe. Which is detrimental for backtesting, and it leads to unrealistic results. To get the actual number of bars available of that timeframe, you should use this security function to get the timestamp for the last (real) bar available. tf=timeframe.period real_available_bars = request.security(syminfo.ticker, tf , LastBarInfo.getAvailableBars() , lookahead = barmerge.lookahead_off) last_available_bar_timestamp = request.security(syminfo.ticker, tf , LastBarInfo.getLastBarTimeStamp() , lookahead = barmerge.lookahead_off)
Pine Script® library
by CyberMensch
FunctionZigZagMultipleMethodsLibrary "FunctionZigZagMultipleMethods" ZigZag Multiple Methods. method(idx) Helper methods enumeration.   Parameters:      idx : int, index of method, range 0 to 4.   Returns: string function(method, value_x, value_y) Multiple method ZigZag.   Parameters:      method : string, default='(MANUAL) Percent price move over X * Y', method for zigzag.      value_x : float, x value in method.      value_y : float, y value in method.   Returns: tuple with: zigzag float direction reverse_line float realtimeofpivot int
Pine Script® library
by RicardoSantos
11