Algorithm to convert timestamp to a human-readable datetime

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 .... :slight_smile:

See 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?

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 to find out your time zone

Formats supplied


You should make the input for it read only

Good idea :slight_smile:


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
untitled script pic (25)

M/d/yy for those people who live in countries that are date challenged :slight_smile:
untitled script pic (26)

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?



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 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 :slight_smile:

....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 :slight_smile:

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.