It's 'fine' I guess.

My honest answer is it seems to be just UTC and Unix time .. which barely scratches the surface of epoch times I've commonly encountered at various parts of my career over the past four or so decades.

eg:

  The C# programming language and Windows NT systems up to and including Windows 11 and Windows Server 2022 measure time as the number of 100-nanosecond intervals that have passed since 00:00:00 UTC on 1 January in the years AD 1 and AD 1601, respectively, making those points in time the epochs for those systems.

So, not handy for that time I was working with raw NT time values.

Another one is raw GPS time packets use an epoch time of "lapsed since last sunday midnight UTC" (more or less and if I recall correctly - certainly it was a weekly rollover count value) so for anyone that down and dirty dealing with raw packets there's an epoch you'll work with.

Astronomers now commonly designate calendar dates by Julian Date (JD), which is the interval of time in days and fraction of day since the epoch 4713 BC January 1, Greenwich noon, according to the Julian proleptic calendar.

The modified Julian Date (MJD) is defined as the Julian Date minus 2400000.5. Thus J2000 is MJD 51544.5.

There's also that twist about noon based earth relative solar day time and fixed star relative Sidereal time which'll crop up for those that dabble in off world data streams.

https://en.wikipedia.org/wiki/Sidereal_time

And there's more ... (but I fear boring dear readers).

So, ... not bad for a basic unix time converter, pretty basic for people dabbling in professional STEM cross platform time applications.

Sorry for wasting your time on this post and thanks for detailed feedback.

This is just a fancy UI redesign of existing epoch converter website. Definitely not intended for astronomers and scientist. :)

No drama, my time is mine to waste as I choose :-)

I worked in STEM instrumentation, multi channel data aquisition, merging, interpretation, and analysis - geophysics, engineering (civil / mechanical kind), astrophysics practical support work (timing, gears, gadgets), etc

When I wrote an epoch tool it was many years ago, fully CLI with a neat ASCII table layout less than 80 chars wide, compared multiple selectable epochs against each other and came with a .config file to name and define various epochs.

Pretty much every data aquisition run for various reasond had it's own "epoch" as multiple instruments were all zero'd against a calibration start ... and we're not even going down the rabbit hole of instruments on opposite sides of the planet each heading in an opposite direction and having to account for propogation time through the width of the planet.

Nice site, could see myself using it. But please, allow also changing to usec and nsec. Plenty of software uses uint64 for nanoseconds since epoch, it'd be nice to be able to convert these as well.

Deployed the changes. Added support for micro and nano seconds. Try it out.

Amazing thing, bookmarked! Will save me lots of time, thanks.

> Don't solicit upvotes

https://news.ycombinator.com/newsguidelines.html

my bad, not aware of it. not able to edit and remove now.

I think you're fine. The guidelines also say:

> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.

I also think the old epochconverter UI was dated. I'll switch to yours

That'd be `date -d @[epoch]`.

Mostly i want to know the relative time of epoch, so prefer a consistent site.

Epoch time is absolute. The above command outputs the epoch time expressed with normal notation in your local timezone. No 'site' would be involved.

This is much nicer. I like the code examples. You sir just got yourself a bookmark

thank you.

Postgresql icon seems to be missing

fixed it. thanks.