I've been wanting a non-JavaScript timestamp->YYMMDDHHMMSS reporter for sometime (pun intended) and I've finally found a Python program for it
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 .... 
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?
Current state of project
*Note: Requires Internet access to https://worldtimeapi.org/api/ip to find out your time zone
Formats supplied
You should make the input for it read only
Good idea
Timezones
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
e.g
d/M/yy
or
M/d/yy for those people who live in countries that are date challenged
AKA the US?
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?
Yeah.
IDK.
Major change
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 https://worldtimeapi.org/api/ip address
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!
@warped_wart_wars
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).
Ok.
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.
