I've just naively transcoded it to get the basic time elements using it.
Original naive Snap! implementation (assumes timestamp is in seconds not milliseconds)
I'm now working on turning it into comprehensive timedate library block(s) - this make take some time ....
later post in the thread for developments
Hmm.. Very similar to this block:
But very good as well, where did you get that code?
Have you got a link to that block to save me having to carry on?
A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.
Current state of project
working reporter that handles all the standard existing Snap! datetime values but using any millisecond defined timestamp
Extra formats added for day and month names including their 3 letter abbreviations
full human readable (DDD MMM d YYYY HH:mm:ss) added
yyyyMMddHHmmsszzz plus many others in a sub-menu - see help for details
And now you can request any format you like using a list
Added reporter to convert yyyyMMddHHmmsszzz datetime to a timestamp as well
Day of the year added
Negative timestamps and datetimes before 1970 handled
*Note: Requires Internet access to
https://worldtimeapi.org/api/ip to find out your time zone
You should make the input for it read only
I haven't come up with a workable method (apart from one really, really slow one) for dealing with timezone/DST offsets
So, for the moment, I'm just going down the route of people having to add in their own timezone offset (if wanted/required)
If offset = 0, then the values returned will be in UTC, not local time as the built-in reporter uses
As well as the reporter returning a standard yyyyMMddHHmmsszzz datetime string, I've also made it return pretty much every format you'd want
And now you can request your own datetime formatting
M/d/yy for those people who live in countries that are date challenged
It doesn't make sense why we format it like that, but at the same time it also makes sense, because when writing a date out in full we say June 17th, 2022.
Does this mean countries who write it out as dd/mm/yy say it like, 17th of June 2022?
Reporter now determines your local timezone offset from UTC and defaults to using your local time zone
The current method requires your computer has Internet access to the
And I've now added the reverse reporter that converts a yyyyMMddHHmmss datetime to its equivalent timestamp
Just discovered that timestamps can be negative so now working on making sure the blocks can deal with that!
This is a wonderful rabbit hole I'm down
....4 days later - still working on it!
I'm from Australia and you can say 'June 17th, 2022', but for me '17th of June 2022' is more naturual (or natural for you).
I've never heard that before, but I would know what it meant.
Maybe after contacting the API you can cache the result for offline use
Good idea - it could store the offset in the browser database and then if Internet isn't available but a previous offset is available then it could use that.
Would only give wrong result if someone moved timezones with a laptop and didn't have internet access at new location.
Which would be a very rare event hopefully
Maybe you could use the built in date blocks to determine the time zone by calculating the current UTC hour from the time in milliseconds, and compare that to the result from the time in hours. This is assuming those results are affected by the user’s timezone.