• (nodebb)

    Time stamp generation is platform dependent BTW. So accuracy is never guaranteed, often only sequentiality is guaranteed by various platforms. In other words, a lot of platforms still only support ms accuracy and the ns part is purely fictional. This might not be important for a local only application but as soon as more than one machine is involved it matters. A good example is two clients creating a record in a DB; it is very much possible that the faster client generates a timestamp that is greater than the slower one when you enter the area of accuracy uncertainty.

    Now when it comes to v7 UUIDs, they are only marginally useful and more a workaround for a design flaw, especially when it comes to relational key generation in DBs. Don't get me wrong, UUIDs are useful in a CQRS context as ALTERNATE keys, but nothing beats the performance of a 64-bit auto generated key. Even DB with direct GUID support like MS SQL plain 64-bit integers are at least twice as fast for every operation beyond the initial INSERT - which can actually accumulate nicely when a lot of JOINs are involved. So when it comes to performance gains, which is literally the reason why v7 became popular, there are other design considerations which result in way greater benefits.

  • (nodebb)

    they use UtcNow and not Now, thus avoiding situations where collisions also happen because of time zones

    I'm showing my inexperience here, but how is that true? The server is the one making that call, not the client, and the server stays in one time zone.

  • Wyatt (unregistered) in reply to dpm

    Daylight Savings Time

  • (nodebb)

    Some twenty years ago I had written a utility that used a popular toolkit to generate DICOM UIDs. The toolkit's algorithm used MAC address, timestamp, and process id. Running the utility on the Windows 2000 (or NT?) command line to generate multiple UIDs, such as

    dcmuid & dcmuid & dcmuid

    yielded the same UID three times, because windows timestamp granularity was poor and process IDs were reused. I became enlightened.

  • (nodebb) in reply to Wyatt

    Given that the "input" to this code (microseconds % 1e9) repeats every 1000 seconds (16 minutes and 40 seconds), a glitch once a year because the hour of 2:XX am is repeated is neither here nor there. Besides, we don't know if the server time zone is configured to be something that even has DST. Example, what if it's in Arizona or Hawai‘i?

  • (nodebb) in reply to dpm

    Never use anything but UTC in your logic, time zones are a presentation issue.

    Time zones result in a time stamp that is not unique, not permanent, not reliable, not complete, not without double meaning. Some time zones feature some of those attributes, some all of them.

    A good example is day light saving: It means you time stamp will miss a certain amount of time in the year while the same amount will be occurring twice. Another example is that time zones are completely politically motivated in their creation and rules of validity. For example the city of Vienna had in it's history at least two and when CET was adopted parts of Austria already used it like railways for years. It's simply put a mess when you need to handle historic data as well because there is hundreds of time zones all with overlapping properties and nonsense.

    To put it short: Never ever use anything but UTC in your business logic, because not doing so you already implemented it wrong, either for the past, right now or the future. In the best case scenario it's a time bomb waiting to explode.

  • (nodebb)

    Never ever use anything but UTC in your business logic

    I never do. UTC in the database, local time in the front end.

    But that's not my question. Remy said "because of time zones", not "because of Daylight Saving Time" . . . those are different issues.

  • Pag (unregistered) in reply to dpm

    Remy was making a joke.

  • (nodebb) in reply to dpm

    Ah, day light saving offsets are part of time zones (also called rule sets due to historic changes including renaming of time zones): https://www.iana.org/time-zones

    For example the time zone Central European Time (CET) also called Middle European Time, has the normal standard variant and a daily saving variant called Central European Summer time (CEST). This is just a name to clarify what is going on, it's not it's own time zone which is still CET.

  • (nodebb) in reply to MaxiTB

    👍 - But even 'smart' bussines-side people can be hard-of-understanding this.

  • (nodebb)

    @dpm ref

    they use UtcNow and not Now, thus avoiding situations where collisions also happen because of time zones

    I'm showing my inexperience here, but how is that true? The server is the one making that call, not the client, and the server stays in one time zone.

    The code is C#. We don't know whether it's running on one client, many clients, one server, or a group of servers.

  • (nodebb)

    Is no one going to talk about KSUIDs? https://github.com/segmentio/ksuid

    Yes, the reference implementation above by SegmentIO is in Go, but nice people have ported it to other languages too.

  • LionKor (unregistered) in reply to MaxiTB

    Oh, but for that to even be considered, you'd need to sync the clocks of both machines.. Good luck, isn't that (mathematically) very difficult?

  • (nodebb) in reply to dpm

    The server is the one making that call, not the client, and the server stays in one time zone.

    There's only one server is there? The version of the story I read doesn't say that.

  • (nodebb) in reply to Steve_The_Cynic

    Given that 3600 % 1000 is 600, not 0, there may be a 600s or 400s discontinuity in the counter at the DST switch times (if Tick has a discontinuity; I don’t know .NET and its doc is not specific enough for me to be sure). Given that it is about half the size of the 1000s window, it may not matter if the safety margin is high enough. I would not bet on that.

Leave a comment on “Time for Identification”

Log In or post as a guest

Replying to comment #676783:

Log Out

« Return to Article