Should dates be strings?

ISO8601 / RFC3339 for life.

> CSV

Yes absolutely and always. Dates are too complicated, requiring to much context, with too much to go wrong, for any non human readable format. At least with strings other systems have half a chance of parsing them correctly, or at least parsing them in a transparent manner.

Or to put it another way, they cannot be trusted to engineers to get it right everytime.

It’s not just a matter of trust. Locale specific datetimes in the future are simply not computable to a point on a number line in the general case. Some locales have date changes that must be determined by the local government every single year. Israel is an example of such a case.

Unix timestamp (actual reference with easy math) + timezone give you absolute time to work with, such that you can work out the correct presentation for the timezone even if the timezone has undergone multiple revisions in the intervening years.

There's still a bunch of problems (timezone of event origin? Event reporting origin? Server? Client? Client + presentational overlay?) and confusing things to work through (including relativistic problems) but the consistency of the reference point is valuable. Nobody is going to confuse what timezone you are using as your point of reference when you use Unix epoch. Just use a 64-bit number to hold it.

The suggested approach simply doesn’t work, because human calendars simply don’t work that way.

If the state of Indiana decides this year to change when they set their clocks forward and back, and you stored your appointment datetime as a timestamp, when do you show up for an appointment? At the new 930 AM after statutory date adjustment, or the now incorrect time stamp in your database? Will the DMV respect your claim that you had an appointment at epoch timestamp 1726651800, or will they say sorry buddy the clock on the wall says 9:30 AM, you missed your window? Are your taxes next year due at 1713173400, or are they due at midnight April 15th?

This is NOT a UI issue. This is an issue where the timestamp you calculated in the past literally does not mean the same calendar date in the future as it does now.

And if your answer is to recalculate the timestamp based on locale changes, what was the point of storing the timestamp? (I hope you stored an audit trail of the locale as well as the timestamp, otherwise you can't even recompute the timestamp). The timestamp is never the ground truth, the human readable string is the ground truth.

The timestamp for a particular human date time is not generally a computable function, because human governments change how dates are reckoned frequently, and the human government, not your database are the ground truth.

Very good point, which is a reminder that you have different "types" of dates that you may want to store.

Went storing the time at which an event happened (e.g. for a system log) then a UTC or UNIX time works, and it will be transformed at display time depending on the user's timezone.

When storing a future time at which to do something, it should be stored with its target timezone so you can always make sure it happens at the right moment. For this iso datetime representation makes a lot of sense.

That is exactly was I was referring to with needing to know whether it was an origination stamp or what, ie the context of the stamp. That problem holds regardless of the format you store the stamp in, because even if there is a colloquial understanding of how to interpret a time change (1030 on Thursday is still 1030 on Thursday) it doesn't hold for every context (5 hrs from now is still 5 hours from now, except if when you said 5 hours from now you meant clock time)

> If the state of Indiana decides this year to change when they set their clocks forward and back

On the other hand, the state of Indiana could just as easily solve most of our time issues by passing a law declaring a day to be exactly 24 hours ;)

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

Not really.

I mean, sure, serialize them as ISO8601 strings, but, no, dates are fundamentally not strings, and that shouldn't be their basic internal representation in most sane systems.

In CSV, though, everything is strings. But the question there is what string format.

the question is what format. what you're really doing is storing a slash-separated CSV of integers with only one entry, and storing a set of integers is what many old systems already did.

the real solution is to store 64-bit seconds (or perhaps 96-bit microseconds, if you need precision) since some epoch, like jan 1st 1970. it's a simple integer that monotonically increases with a defined starting point. you can't get any more simple or reliable than that.

the unix time stamp was a wonderful solution, they just chose to use too few bits for how long their system would end up living. 64-bit integer seconds will last something like 42x the age of the universe, so that ought to cover things.

Dates / timestamps fail to capture an 'event'. At best they are a partial event specification with the assumption that they are converted correctly to an assumed increment along a single time scale.

Event specification is a very complex and politically entwined idea. This involves not just a frame of reference for the time, but also a location within which that time should make sense. Otherwise it is impossible to derive the correct rule-set for evaluating the human interpreted value of that moment.

An alternative which might make sense is to force people to specify which ruleset they desire with the offset value within said ruleset.

Sadly, my preferred representation of time isn't expressed in either of the popular standards (RFC 3339 or ISO-8601). https://ijmacd.github.io/rfc3339-iso8601/

RFC 3339 gets closet to my preference with: 2023-09-17 23:51:41Z

However these are examples of what I'd prefer to see:

  * 2023-09-17 23:51:41 Z UTC
  * 2023-09-17 16:51:41 PST8PDT USA/WA/Seattle
  * 2023-09-17 16:51:41 PST8PDT Canada/British Columbia/Vancouver

Note: At the moment Vancouver BC and Seattle WA happen to observe the same time offset but are in different political locales with different DST shift times. I'm not sure if it's still correct to call either timezone PST8PDT... that may imply the USA/CA/Los Angeles.

Time would be expressed numerically 'large endian first' format, with zero or one punctuation element between units, preferably expressed with individual units matching the most correct (easiest for a human to read what they expect) value at a glance. This means - (or no separation) for dates, and : (or no separation) for HMS. (Space) or _ (Underscore) are preferable for between units. The timezone 'name' follows the smallest unit of time, which is itself followed by the reference city. Implicitly events in the past were accurate at the time they were encoded, while events in the future might need re-validation and conversion if the rules have changed. Though it would be even smarter for the human important metadata (a string, probably) of recognizing the future event(s) be stored rather than a precise moment which may be incorrect.

Locale and time are two separate pieces of data. Why store them together? Why not unix time and locale as two separate data points, and then mapping them to a human readable value is a UI concern?

They are not, though it may be implicit in your thoughts that E.G. UTC or TAI or some other standard is associated with a single scalar value which represents some time along that frame of reference.

However not all times are generated within such references. Most frequently (when sampling human facing outputs) times are printed within some other reference frame. As I tried to elaborate that usually relates to political realms, and there even cities may not be a sufficiently precise specification. (Offhand E.G. would timestamps from east and west Berlin while it was divided differ? I've not memorized that trivia, but it is one example of a politically divided city.)

Further, not so many decades ago timezones along the western Americas coast happened to match, but have since diverged at times during the year due to political changes in timezone observations. It is not inconceivable that actions at a state, county, city, or other zoning level (E.G. Provences for Canada) might further change the meaning of a human friendly representation of an event (time in a place).

That makes sense, but really we are not going to be able to guarantee full accuracy of a timestamp against future changes in timezone boundaries. I guess if you had a GPS coordinate, that could be done, but it would be a monumental task for little benefit. Which is why IMO time data should be stored in unix, because then we can at least guarantee that we have an accurate ordering of events, at least within the precision of the timestamp.

Would rather convert to unix at the time the event is recorded since we will be able to convert to the unix standard from whatever locale. If we store timestamps with a locale then we have to worry about the exact type of locale changes that you mentioned, and there is no guarantee that we will even know how to translate the locale that was stored at the time the TS was created. Sure, unix could change too (e.g. leap seconds), but I would be much more confident that time libraries will handle such changes

You're going to need to answer https://news.ycombinator.com/item?id=37551163 before you continue with any more of this.

Otherwise this isn't going to be a meaningful discussion.

you're stretching the definition of "event" pretty far there. if you're not referring to an atomic-clock-precise instant in time, you're going to need to elaborate as to what your definition of an "event" is and explain why location/culture/politics are important.

at any rate, if you even want to have a hope of keeping track of any of that stuff, you're going to need a rigorous and atomically-precise physical standard to actually map it all to. look at the tz database. it's a set of mappings that ultimately rely on such a standard of atomic-backed time.

> it's a simple integer that monotonically increases

It isn't. See leap seconds.

Using a string would allow you to distinguish UTC from UT1. Only UT1 is monotonic.

I specifically did not say "UTC" at all. Read my actual comment.

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

"Unix time is a date and time representation widely used in computing. It measures time by the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch, without adjustments made due to leap seconds."

Unix time does not include leap seconds or other adjustments.

> Unix time does not include leap seconds or other adjustments.

It does. You've been misinformed.

[Edit] wait, Wikipedia contradicts what other people have told me. It doesn't cite sources though.

That only matters if you care about taking leap seconds into account. If you want atomic clock time, not mushy political calendar time, then an integer number of ticks suffices.

Would you prefer if I used the article's term of "precise time"?

At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>, than a dumb "01/01/99" string of integers that rolls over and breaks at Y2K. (with associated fun parsing bugs)

> At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>

No, it is not always better. If you want to store when a contract is going to end you don't want care how many milliseconds are between now and then. You care that it happens exactly at midnight of the last day of the year. Not an hour earlier or later. Even when politicians intervene between now and then.

Wrong problem. None of what you're talking about is even remotely relevant.

If you can't establish accurate precise time, you have no ability to handle all that political crap layered on top. You're trying to solve a top-of-stack problem in the bottom-most layer.

Look at the tz database, the way in which the problem you think needs to be solved is actually handled. It implements all your mushy ever-changing political end-of-day end-of-week crap as a table of conversions to precise-time seconds.

In theory yes, in practice no. When you store a future contract end date in seconds/milliseconds/microseconds since some epoch. You will do that with tz database version x. A few year later some admin updates the tz database. Now you have to remember if you have to reencode your timestamps or not. To do that correctly, you need to store the version of the tz database that was used, translate it using that version to a "human-readable" date and translate it back to the the timestamp with the latest version of tz. If you don't do that you will experience silent data corruption.

Everyone - especially those in my own team - told me that dates needed to be human readable strings in my APIs and messages, but I ignored them and used Java time stamps (Unix, but milliseconds) instead.

Lo, nobody complained about the readability because most time problems are relative to other events, rather than to a specific clock time. It’s so much easier to work out that two events occurred a few milliseconds apart when you don’t need to take segmentation (ie: ymdhms.s) into account. And using an integer obviates time zone and daylight savings corner cases. You can simply subtract two numbers and get useful information. And it’s much easier to do the math in your head and in scripts.

For those relatively rare times that you do need to know the clock time, there are CLI tools (ie, date -s) and websites galore.

Of course my use case was not everyone’s use case. But I ignored the blanket recommendation to use human readable time, and despite the naysayers, life became much easier for me and my team. I doubt that I would go back to string timestamps for any purpose.

Honestly, human time is for humans, it’s a presentation problem. Computer time is for computing.

Leap seconds and UTC vs UT1? Even in your use case, this would matter.

> It’s so much easier to work out that two events occurred a few milliseconds apart when you don’t need to take segmentation (ie: ymdhms.s) into account.

IF you know they occurred a few milliseconds apart, integers are marginally easier.

  1695029423495
  1695029423502

  2023-09-18T09:30:23.495Z
  2023-09-18T09:30:24.502Z

But for every other case, it's much harder to discern the difference.

  1695029423495
  1695029483502

  2023-09-18T09:30:23.495Z
  2023-09-18T09:30:25.502Z

It's far easier to compare these using the commonly practice of ISO 8601.

that’s the argument I kept hearing, but in practice, it’s trivial.

    1695029423495
    1695029483502
    2023-09-18T09:30:23.495Z
    2023-09-18T09:30:25.502Z

In fact I can see by just looking at your integer timestamps that it’s about 60,000ms difference, or 60 seconds, so I think your time stamps are wrong.

I personally find that it's much more difficult to compute the number of seconds between those timestamps without help, and that’s my point.

Dates should be integer seconds since epoch. Timezones are essentially a UI concept, so the date should always be stored and passed around as an int — and then only transformed into a user-readable string on the client-side at render-time, when it's necessary for a human to read it in that format.

For some systems, you may want more precision, in which case millis (or nanos) are reasonable, as long as you choose a big enough int type to hold them.

Once humanity goes from 1 planets to N planets, the whole thing will become a mess again thanks to relativity, and software engineers of the future will have to deal with figuring out how to convert an Earth timestamp to a Martian timestamp — and what it even means for two timestamps to be "equal" then.

But that's next century's problem. ;)

Not sure what you mean by passing the timezone as int.

Edited a few words and punctuation marks to make my intent clearer; hope that helps. The idea is to deal with the timezone at render-time, not to pass it around.

When you store the time of a future event (like a reminder for 1 year from now), and integer since epoch does not work.

Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen. However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.

Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.

> However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.

This is a really interesting scenario that I hadn't considered at all. You're totally right; this approach breaks down there.

Off the top of my head, it looks like this scenario would require manual action either way, though. Either it's an update of the packaged datetime library to incorporate this new regulation, or it's a database migration to update the timestamps for affected users.

The same goes for "times this business is open" to store "9am-4pm on weekdays" you probably want to store almost exactly that string, rather than some ints. Generally speaking, dates stored as "ints" are mostly good for timestamps of events that have already happened (or even more precisely events that your application generated/logged live). Other use cases may be more rooted in the "human" dates than in absolute time

> Timezones are essentially a UI concept.

Sometimes they are, sometimes they are not.

For example...date+time of birth. The legal date (timezone) is a significant part of this event's time.

> passed around as an int

We're talking about a CSV. CSV don't have ints.

You can use base-10 encoding of the Unix timestamp, or the ISO 8601.

Yes to ALL of that.

I would add that a UI might prompt for a date as well, which of course would be entered using a local time input element based on the the users time zone. But that local time would immediately be converted to an int and passed to an API.

Depends what they're for, to say 1000 hours from this point in time, no, to say at 10am in your local time zone in 100 days, yes.

If it's in the past, no

There have been a few times at work where someone says “people use two digit years, can’t we just store two digit years?” To which I reply: “that’s literally the y2k problem”, usually gets us back to four-digit years.

Personally I use four-digit years even when I'm writing the date on some food that I'm putting in the fridge -- somethng that needs to be thrown away before the end of the week let alone the end of the century -- but at the same time I'm thinking to myself what a pedant I am.

Let me applaud that! Small redundancies like these in writing lessen ambiguity and cognitive load. Although "2023" is longer than "23" it is more readily apparent as a year when e.g. looking/scanning for dates in the fridge. You might be saving your future brain some precious energy in writing full years instead of shortened ones. (Only half joking, the same could presumably be achieved by a well layed out label with ample white space and good typography.)

We used to have to write the date at the top of every work page in school and draw a margin strictly with a ruler. At the time naturally I hated the arbritrariness of it but I really appreciate it as an adult. It feels a lot easier to be confident and break away impostor syndrome when you work with little rituals like this. Similar to how I was taught to write with all caps on engineering documents for legibility. It makes very little actual difference, it just feels professional, and I think inspires me to take a little more pride and care in other areas.

>> "It only takes 23 years to forget history."

I dont think this means people have forgot history, rather, I think people make tradeoffs. You trade off size/space/ease for long-term disruption. Most developers making these decisions now will be close to a 100yo in 2199. It will not be their problem, or even their childrens' problem. Possibly their grand-children's problem.

Alternatively, I could argue that the life of most systems is short enough that 80yrs is too long a horizon to worry about the problem.

> Most developers making these decisions now will be close to a 100yo in 2199.

We're giving people too much responsibility too young.

We’re definitely giving negative seventy year-olds too much responsibility.

On the other hand, the ability to communicate with people several decades before they're born should have promising implications for the in-much-higher-demand ability to communicate with people after they've died.

This is what happens when tech companies start looking down on anyone over the age of 30.

Do people under 30 care about an extra 2 bytes in a date object?

Probably, as a lot of people from the current TikTok generation might lack the attention span to read more than two digits, or rather four digits till the end. Embedding some random game's gameplay and audio into your financial export to keep them engaged would increase the size by a couple of magnitudes, too.

"There are 5 differences between these two spreadsheets. Can you find them all?"

Sure, but the cost of 2 bytes is a lot different now than it was in 1950 (or 1970, or whatever). Store the full year.

Not in this case: They also changed the amount from "5.99" to "5.99 €", so the total number of bytes went up (3 bytes for the €).

If they've got the explicit space in there, then four bytes!