Some events don't take place at any specific time and instead are meant to be valid for the whole day irrespective of the time zone the user is at.

For the sake of argument, let's say a system sitting on a server (up in the cloud) runs a job at 5 am and imports data from a different system between this run and the last (24 hours ago). The actual user sitting at his desk doesn't know when the job runs, the user only knows that they go to sleep at night, the server crunches all the entries for the day.

The next morning the user wants to see all the entries from yesterday (what ever the job produced) and they go to the app, pull up a calendar input selector and they pick the 5/26/2022 (today being 5/27/2022).

Assuming the developers followed best practices, the client will transform the date into it's UTC version and send it up through an API. Chances are, depending on where the user is located and the server is, there might be a mismatch.

I could send the date up without it being UTC or I could send a UTC date and try to adjust it back to local time so that I could then compare with the date on record (that exists without an actual time zone).

What I am asking is: What's the more conventional answer to this particular problem?
Is the idea of a date without time or time zone just ridiculous?

CodePudding user response：

Use UNIX Time. It will give you a timestamp that is universal no matter what timezone the user is in. You can then convert it into whatever timezone you want to.

CodePudding user response：

The concern you describe is well solved/addressed by the ISO 8601 dates/time presentation protocol.

All modern software can read/write dates in ISO 8601.

In Unix machines, the correct command is date with option -I

   -I[FMT], --iso-8601[=FMT]
          output date/time in ISO 8601 format.  FMT='date' for date
          only (the default), 'hours', 'minutes', 'seconds', or 'ns'
          for date and time to the indicated precision.  Example:
          2006-08-14T02:34:56-06:00