This topic contains 13 replies, has 4 voices, and was last updated by  erictdavid 8 months ago.

lua date parse error

  • Hi, I am getting a date format 2016-07-11T13:28:19.0000000 in one of my values returning from a form which date parse is unable to understand. It is a milliseconds in fraction value and I am getting a lua date parse error

    Please can you advice how I can include lua to understand this date format. I am getting a nil error when I try to add the code

    help would be appreciated

    It must be more than milliseconds, given that the ‘0000000’ suffix is seven digits.

    If you don’t care about time precision to 7 decimal places, you can use a custom format to parse that date:

    require "dateparse"
    
    function main(Data)
       local rawDate = "2016-07-11T13:28:19.0000000"
       local parsedDate = dateparse.parse(rawDate,"yyyy-mm-ddwHH:MM:SS.ssss")
    end

    Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

    Hi Jeff,

    Thank you so much for this. Yes, the precision of the last 7 digits are not considered. It works now, I didn’t realize that I could use ‘w’ for ignoring characters.

    Appreciate your kind help

    Regards,

    Eric

    Hi Jeff,

    Ahaa…unfortunately, we do need to consider the digits after the decimal. Just talked with my team ..

    if that’s the case, can you advice what are the options I have?

    Regards,

    Eric

    Slice it off with a bit of string manipulation. Play around with the string.sub() function.

    Hi Elliot,

    Thank you, Yes, I was beginning to think that would be the best way. Will update on how it goes

    appreciate your guidance

    Regards,

    Eric

    you’re welcome.

    Hi Lev,

    Thanks for once again reaching out to help me.

    So we are collecting files (excel) from a SFTP server and then parsing the data in those files and getting a date time of when it was done. It worked perfectly fine (2016-07-11T13:28:19Z) until we get this format (2016-07-11T13:28:19.0000000) and that’s it the program stops and returns an error.

    Our goal to fix the solution was one to add a format that will accept the date format so it can carry on with the processing.

    Thank you for the suggestion.

    Will update on how we resolve shortly. in the mean time if you have another idea please do let me know

    Regards,

    Eric

    don’t change the dateparse module. it is controlled code with versions. instead of it create a little helper function to massage time value before passing it to dateparse module.
    use string built-in functions to chop off the 7 zeroes or to replace them with something hardcoded that does work for you and doesn’t upset the dateparse module.

    Can you tell us exactly what the 7 digit value represents? Is it really sub-second time at a precision of 7 digits, or do the trailing 4 digits represent a timezone offset (or something else)?

    Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

    Hi Jeff,

    So this date is what I get from my files. we take that value and we parse it like this;

    x = os.date(‘%d/%m/%Y’, dateparse.parse(x))

    but this returns an lua date parse error unknown date/time format. I am assuming it is the seconds fraction.

    Regards,

    Eric

    You mentioned in your response to me that you need to consider the digits after the decimal in your code, but you didn’t say what you expect them to represent. If they represent a fraction of a second, then that’s some serious precision provided by the source system: 1/10,000,000th of a second.

    I have a hunch that’s not really what that value is supposed to represent; my guess it’s some way for the sender of these files to prevent filename collisions, and may not actually be significant for anything but auditing purposes.

    If the final recipient of these files attaches some significance to the 7-digit suffix, your only choice is to split the date on the period character and store the suffix in some structure that will be sent to the data’s destination.

    Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

    Hi Team,

    Would like to let you know that they accepted the solution (Jeff’s) that you gave at the beginning. We didnt have to go into detail to provide exact information.

    Looks like the fractions were not important to the decimal. Jeff, on verification, we just had to check if the format was understanding different fractions 🙂

    Regards,

    Eric

Tagged: 

You must be logged in to reply to this topic.