Timestamps done right
getkerf.wordpress.com
Timestamps done right
1–10 of 74 posts
Re: Timestamps done right
#2> I mean, just try it in Java.
For ages JodaTime actually nailed it, and the Java 8 date API was based off this.
> Not an add on type as in R or Python or Java.
Again, let's talk about the modern version of the language and not act like prior screw ups are the end all for a language.
Also
> 2012.01.01 + 1m1d
How is that more clean than:
> new DateTime(2012, 1, 1).plusMonths(1).plusDays(1)
Re: Timestamps done right
#3Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?
Re: Timestamps done right
#4This is just an aside, and not a knock on the article, but Java does have a built-in Timestamp type, [1] and has had it for some time.
Maybe it's not "first-class" (not sure what this means in context?), but it's definitely there and not in a third-party JAR or anything.
However, it's bad for other reasons, the first being that it extends java.util.Date (the Javadoc seems to admit this) and combined with the related java.sql.Date (which also extends java.util.Date) makes for a very confusing API.
For this reason, Oracle recommends just using the new Date APIs, [2] and mapping a SQL TIMESTAMP to LocalDateTime.
1. https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp...
2. http://www.oracle.com/technetwork/articles/java/jf14-date-ti...
Re: Timestamps done right
#5Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?
You still need to record the timezone somewhere and you might as well just stick to ISO8601/RFC3339 format then.
Re: Timestamps done right
#6This post doesn't load at all for me without javascript.
Re: Timestamps done right
#7Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?
They are difficult to read for humans. Without using a computer can you tell me when this timestamp was taken? 1453383978
Ultimately that was the point of the article, but the tone of the article about how they got it right and everyone else is wrong bugged me.
My approach has been to store everything in epoch form, do all of my calculations and manipulations from there, then build tools that make converting back to a human readable representation when and where it is needed. I think the idea that you have a problem completely solved though just prevents the search for any improvements.
Re: Timestamps done right
#8Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?
You still need to record the timezone somewhere and you might as well just stick to ISO8601/RFC3339 format then.
One approach is to store numeric timestamps in UTC format. Then if you do have data stored in a different timezone you have to include the timezone with it. That is the default mode of operation for many of the standard date formats.
If you get timestamp data from a system outside of your control though you always have to make sure you know what it means. At least half the time it seems like a date without a timezone isn't UTC, but in whatever the originating timezone was but the developers didn't include a timezone offset in the data...Timezones....the bane of my existence.
Re: Timestamps done right
#9This post doesn't load at all for me without javascript.
I had a related comment earlier this week:
Re: Timestamps done right
#10 date -u +'%FT%H:%M:%S %Z'