I have noticed that the date and time fields being returned to me from the Nest API are not matching the format that the API documentation lists.
For my thermostat, I am getting the following for last_connection:
"last_connection": "2014-10-27T20:22:12.165Z"
But the API documentation lists it should be formatted as:
"last_connection": "2014-10-27T20:22:12+06:00"
Why is the Nest API returning milliseconds to me and why am I getting the character "Z" instead of the actual timezone offset that the date/time is coming from?
It looks like the example is incorrect with respect to the actual implementation. If you look at the API Reference you will see the time data is all in ISO 8601, which support both string types.
This also means you should likely use a library to support ISO 8601, rather than manually parsing the string if possible.
Related
Inside Logic App:
In my set variable of type string, I am trying to use the following expression. What is the problem here? I get the following error message. The same expression works perfectly for setting the filename in my create blob action.
formatDateTime(convertTimeZone(utcNow(),'UTC','GMT Standard Time'),'yyyy-MM-dd')
After reproducing from my end, I could see that the mentioned expression was working fine. Instead of using formatDateTime and convertTimeZone separately, According to convertTimeZone syntax you can directly use the required format within convertTimeZone itself. Below is the complete expression that will work.
convertTimeZone(utcNow(),'UTC','GMT Standard Time','yyyy-MM-dd')
According to the Official Microsoft documentation, the GMT Standard Time and UTC are in the same timezone and doesn't have any time difference. If that's the case you can use only formatDateTime and format the date time in required format.
formatDateTime(utcNow(),'yyyy-MM-dd')
Result :
I have a timestamp embedded in some JSON data as a string, for ease of inspection and modification. An example looks like this:
"debug_time": 1670238819.9747384,
"last_saved": "2022-12-05 11:13:39.974725 UTC",
When loaded back in, I need to convert it back to a float for comparison against time.time() and similar things, however, I can't seem to find the magic incantations to have it restore the correct value.
In restoring the JSON data, I attempt to convert the string to a float via strptime() like this:
loaded_time = datetime.datetime.strptime(obj.last_saved, '%Y-%m-%d %H:%M:%S.%f %Z')
This does restore the timestamp to a valid datetime object, however calling .tzname() results in None, and my attempts to use loaded_time.replace(tzinfo=zoneinfo.ZoneInfo('UTC')) have not yielded any useful results.
In short, emitting loaded_time.timestamp() yields 1670267619.974725, which is 8 hours ahead of what it should be. I've tried using .astimezone(), in various permutations, but can't find a way to correctly have it convert to the client's local time.
I even tried to hard-code in my own time zone US/Pacific but it stubbornly refuses to give me that original debug_time value back.
This doesn't seem like it should be a difficult problem, but clearly I'm misunderstanding something about how python 3's time handling works. Any ideas are welcome!
Thank you for your time!
you have to use built in function replace like
.strftime("%Y-%m-%dT%H:%M:%S.%f%Z").replace("UTC", "")
I have a requirement where I need the pattern ICU uses to format the given date/time.
For example: If I have something like DateFormat.getDateInstance(DateFormat.SHORT, en_US).format(currentDate) gives me 5/3/2015, then I need an API which can tell me that the pattern ICU4J internally using is d/M/yyyy.
I did figure out a solution, all you need to do is convert the DateFormat into a SimpleDateFormat and call toPattern().
((SimpleDateFormat)DateFormat.getDateInstance(DateFormat.SHORT, en_US)).toPattern() returns d/M/y which is what I almost needed.
I have date string return by ServiceStack : 2013-08-25T12:06:32.8770000 but error when convert to date of Dart
DateTime.parse(mapAccount[Account.RECCREATED]);
it ok when call
DateTime.parse((mapAccount[Account.RECCREATED] as String).substring(0, 26));
Is there anyway to fix it. Thanks you.
Looks like the string don't match the internally used regular expression:
r'^([+-]?\d?\d\d\d\d)-?(\d\d)-?(\d\d)(?:[ T](\d\d)(?::?(\d\d)(?::?(\d\d)(.\d{1,6})?)?)? ?([zZ])?)?$'
But the regular expression doesn't support more that 6 digits for the milliseconds (and microseconds) part, but you supply 7 digits.
The documentation does not state which formats are supported, but gives some examples. They only state that they support a subset of ISO 8601.
Looks like your solution is the only one a the moment.
Not sure if this should be treaded as a bug, but if you think it is a bug, create a bug report here.
See the docs about DateTime.parse for more details. Looks like the problems with the parse function is already in the bug tracker.
i m just stuck with a vxml element in an ssml file in tropo. tropo does not recognize
interpret="time" and i have to put interpret="vxml:time".
But I need to also define the format attribute format:"hms12". so i write this:
<say-as interpret-as="vxml:time" format="hms12">243P</say-as> </s>
but it keeps pronouncing it like three integers.
i searched everywhere for the right syntax but couldn't find something.
I believe that is the default format for Tropo. Leave out the format attribute and make format your value as "0243p" for 2:43 PM, instead of "243P" as you have it. If you do not have your value in the exact format from the source of the data I would just convert it to this format rather than trying to force Tropo to conform to its format.