[HN Gopher] Show HN: A Unix timestamp converter that includes th...
___________________________________________________________________
Show HN: A Unix timestamp converter that includes the micro and
nanoseconds
I find myself having to convert a lot of unix timestamps to a human
readable format, but most of the online calculators I found don't
include the micro or nanoseconds in the human readable output. It's
a small detail, but I find myself having to manually space out the
timestamp frequently. I'm learning frontend development, so I made
this converter to hopefully make it easier to convert timestamps.
Welcome to any feedback :)
Author : surfingninja
Score : 21 points
Date : 2023-03-04 16:37 UTC (6 hours ago)
(HTM) web link (justquickmath.com)
(TXT) w3m dump (justquickmath.com)
| flatiron wrote:
| Reminds me of a call I was on a few weeks ago where someone went
| off that Unix epoch with milliseconds wasn't the Unix epoch. Made
| it a huge point that it wasn't and would correct everyone who
| tried to refer to it as that. I did Google it and he technically
| is right. But it's also a stupid hill to die on.
| IncRnd wrote:
| Your colleague is absolutely correct. That was the same
| objection I had to this. Unix timestamp format is only seconds.
| This page shows a timestamp but not a Unix timstamp, so the
| hill people are dying on here is to take and reuse a name for a
| different format out of their own stubborness - even after they
| learned they are wrong. It's very confusing and rejected by
| tools that only work with unix timestamps.
|
| That said, this appears like a very minor point, but it's not.
| This is how bugs are created.
| 2h wrote:
| exactly. people using milliseconds and calling it a unix
| timestamp are wrong. provably wrong. so for them to dig in,
| or anything other than say "oh you are right, sorry", is just
| a waste of everyone's time. Accept that you made a mistake,
| and move on.
| bradknowles wrote:
| I added a comment to this effect at https://gist.github.com/t
| imvisee/fcda9bbdff88d45cc9061606b4b...
|
| I'll contact the original author as well. This is definitely
| an issue that should be listed in "falsehoods that
| programmers believe about time".
| 2h wrote:
| here is some Go code that does the same thing:
| package unix import "time" //
| 2023-03-04 11:35:43.4859519 -0600 CST func unix_nano(nsec
| int64) string { return time.Unix(0, nsec).String()
| }
|
| https://godocs.io/time#Unix
| vhanda wrote:
| Mate, I'm very confused.
|
| The first result in Google [1] which I often use, lets me paste a
| unix timestamp in seconds, milliseconds or nano seconds, and it
| accordingly converts it to a Human readable string.
|
| Is that not the feature you built this for?
|
| [1] - https://www.epochconverter.com/
| surfingninja wrote:
| Take the timestamp "1677951565000123456" for example - If I put
| it into the link you posted, it just gives me "Saturday, March
| 4, 2023 11:39:25 AM". While it's a minor drawback, it requires
| another step to figure out the microsecond and nansecond part
| of the timestamp since it's not in the output. My website would
| display "Saturday March 3 2023 11:39:25.000,123,456 AM -06:00
| (nanos)", which gives you "000,123,456" telling you the
| milli,micro,nano breakdown of the timestamp
| tzs wrote:
| > Take the timestamp "1677951565000123456" for example - If I
| put it into the link you posted, it just gives me "Saturday,
| March 4, 2023 11:39:25 AM"
|
| It looks like it only gives millisecond resolution in the
| output, and only displays milliseconds if there is at least 1
| millisecond. Give it 1677951565020123456 and then you will
| get 11:39:25.020.
| bitcharmer wrote:
| Exactly. I've been using epoch converter for years. It's the
| first thing that comes up in search results too.
|
| How did this reach the front page?
| lopkeny12ko wrote:
| As someone involved in a lot of hiring, it's very common
| especially for junior developers (which OP appears to be) to
| pad their resumes with many toy web apps that effectively
| wrap or replicate simple Unix tools. I have noticed this
| trend a lot in the last year or two. It does give those
| applicants a leg up for sure, especially in this market, but
| do only take these projects at face value.
| imiric wrote:
| At the same time, we celebrate rewriting small Unix tools
| in Rust. How is that different?
|
| You shouldn't view someone building a toy project in a
| negative light, even if it's for learning purposes. It
| demonstrates curiosity and interest in learning, and is
| part of what being a hacker is all about.
|
| Maybe it's not frontpage worthy for this crowd, but it's
| certainly worth mentioning in a CV, especially for junior
| engineers. It can serve as a good topic of discussion
| during the interview, for example.
| surfingninja wrote:
| See my other response to the parent for the reason I felt
| there was room to improve on the existing websites. Are there
| any other features you would find useful in a timestamp
| converter?
| kushie wrote:
| I got something incorrect, inputting 1777777777 gave me sunday
| may 5 2026 but that day is a tuesday
| surfingninja wrote:
| Thank you for the feedback! I identified the root cause of the
| bug and uploaded a fixed version.
| gdevenyi wrote:
| Doesn't 'date' do this on the commabd line?
| heyoni wrote:
| gdate if you're using home brew on Mac
| donio wrote:
| date +'%F %H:%M:%S.%N' -d @1677954553.2134567654
|
| Adjust the format as desired.
|
| Or if there is the number of nsecs rather than the fraction:
|
| date +'%F %H:%M:%S.%N' -d @$(dc -e '9k 16779545532134567654 10
| 9^/p')
|
| The dc stuff is RPN, k sets the precision, p is print.
| Y_Y wrote:
| If you stopped people from posting about their amazing new
| project that replicates standard functionality from classic
| unix tools we'd have very little left.
| heyoni wrote:
| Cool. Let's stop people from discussing these 'amazing'
| projects then. That sounds productive.
| rsaxvc wrote:
| Looks like you have varying precision with date, might be using
| floating point?
| surfingninja wrote:
| What do you mean by varying precision? Do you have an example?
| Thanks
| rsaxvc wrote:
| At first I didn't understand the input format, which seems to
| try and autodetect the units.
|
| When I enter 1e-3, I get 1ms past epoch start, but 1e-4 is
| 0ms past epoch start. And that isn't what I'd expect.
|
| Here's another odd one, or why I wonder what internal
| precision things are calculated to:
|
| 1234567800000000090.000 is Friday February 2 2009
| 11:30:00.000,90.,000 PM +00:00 (nanos)
|
| But 1234567800000000090.0001 is Friday February 2 2009
| 11:30:00.000,0.0,001 PM +00:00 (nanos)
|
| Arguably, UNIX time was really just seconds, but it is handy
| to have more precision, it just didn't always align with what
| I'd expect.
| surfingninja wrote:
| Thanks for the feedback! I will make sure to fix those edge
| cases with fractional nanosecond values
| amelius wrote:
| Wait, so it determines the units based on the actual number? This
| is really bad!
___________________________________________________________________
(page generated 2023-03-04 23:02 UTC)