Plugin update question on getTimeParting 3.4 > 6.2

[#1]

Hi,

I was hoping for some advice on updating the getTimeParting plugin from 3.4 > 6.2.

It appears the 3.4 code uses  "Utility Function: split v1.5 (JS 1.0 compatible)" which I don't believe is needed any more.

Also the older code needed to have the date ranges for time parting entered e.g.

//US
s._tpDST = {
2012:'3/11,11/4',
2013:'3/10,11/3',
2014:'3/9,11/2',
2015:'3/8,11/1',
2016:'3/13,11/6',
2017:'3/12,11/5',
2018:'3/11,11/4',
2019:'3/10,11/3',
2020:'3/8,11/1',

I assume with the new version of the code the above code is no longer necessary?

Cheers

[DinoF40]

Hi @DinoF40 ,

Your understanding is absolutely correct. The Utility function and the older code is no longer needed. With v6.2, the arguments to pass in contains an optional but recommended parameter t. It's the name of the time zone to convert the visitor's local time to. It defaults to "Etc/GMT", or "UTC/GMT" time. Common values are "Americas/New York" for Eastern time, "Americas/Chicago" for Central time, etc.

Example call: s.evar1 = getTimeParting ("Americas/New York");

[DinoF40]

Thanks for the confirmation.

It would be great if we could have some of the old functionality added back in. The older version of the code we can pull day or hour directly.

e.g. getTimeParting('h', '6'); which would bring back time "11:42 AM" or getTimeParting('d', '6'); which would return "Friday"

Now the only call is getTimeParting ("Americas/New York"); which returns 

"year=2020 | month=March | date=27 | day=Friday | time=12:14 PM"

Would be great if we could just call the deliminatated values individually e.g. getTimeParting ("Americas/New York", "day")

Otherwise we have to add some cumbersome code to get the day e.g.

var fullTime = getTimeParting("Australia/Sydney");
var timeIndex = fullTime.indexOf("time");
var dayIndex = fullTime.indexOf("day");

var time = fullTime.substring(timeIndex+5);
var day = fullTime.substring(dayIndex+4, timeIndex-3);

Or I edit the main plugin code to add additional values, which although simpler, more problematic when upgrading if people don't realise codebase has changed.

Cheers