4 ms·

I was not talking about translations only. Formats for dates and money are available in almost every programming language as library. You don't have to invent

by tdrdt 5y ago

I was not talking about translations only. Formats for dates and money are available in almost every programming language as library. You don't have to invent this yourself. The same for timezones, as long als all dates in your DB are UTC. And inputs for phone numbers and addresses fall in the category of 'Falsehood programmers believe about...'. If you store your data normalized all the programming language locale libraries make your life easy. /2c

mro_name 5y ago
> as long als all dates in your DB are UTC. times don't have to be UTC but need the timezone info attached - be it implicit (all are UTC) or explicit, e.g. in text form rfc3339. Stripping the time-zone is information-loss and usually not desirable.
- 5Qn8mNbc2FNCiVV 5y ago
  You combine UTC with the Timezone of the user when it's rendered out and when you don't have that time (f.e. email to customer) you'll have to get a bit creative and calculate the timezone with the user data you have. If you only have an email and no other data, you include the used timezone so they can calculate their local time from that themselves.
  - Scarblac 5y ago
    To keep all information, you also need to store the timezone that the event originally was. E.g. When comparing temperature charts from different places in different timezones, you may want to show them in a way that "noon local time" is on the same place of the X-axis in both cases. Or more usual: I keep a log of what I do during a day. If I now move to another timezone and want to look at the log, I don't want the times shown in my current timezone. I want the timezone I was in back then.
- grey-area 5y ago
  All that tells you is the timezone the user was in (or if you're unlucky the timezone the server was in) when the data was recorded. So it's not usually very valuable information. It doesn't tell you anything about the time zone this particular user would want to see it in today, which depends on quite a few factors including where they are and what the timestamp relates to (booking, event, log of past events etc).
  - Scarblac 5y ago
    Well, garbage in garbage out, of course. But in applications where it matters, you make sure you know the source timezone where the data enters your system.
    - grey-area 5y ago
      Which applications does it matter for?
      - shpx 5y ago
        This can matter when timezone definitions change, such as when a country decides to start/stop following daylight saving time. If I schedule something for 1 pm 6 months from now, and a transition to/from DST is supposed to happen at some point during those 6 months, and then my country decides to not follow DST anymore or to follow DST year-round, once you update your timezone database and convert your UTC stored time to my timezone, it's going to either be 12 or 2 pm now. This is probably not what users want, unless they scheduled the event to happen a certain time interval after some other event that's not affected by timezones.
        grey-area 5y ago
        Thanks, I was thinking more about an application that requires it day to day. So a future event made before the time zone transition of a country? That's rare enough that I think a one-off transition plan would be fine. Given the downsides of storing dates with time zones (comparison, confusion etc), it doesn't seem very attractive to me.
BiteCode_dev 5y ago
The debate that started this thread proved my point without needing any effort of my part :)

by tdrdt 5y ago

mro_name 5y ago

> as long als all dates in your DB are UTC. times don't have to be UTC but need the timezone info attached - be it implicit (all are UTC) or explicit, e.g. in text form rfc3339. Stripping the time-zone is information-loss and usually not desirable.

5Qn8mNbc2FNCiVV 5y ago
You combine UTC with the Timezone of the user when it's rendered out and when you don't have that time (f.e. email to customer) you'll have to get a bit creative and calculate the timezone with the user data you have. If you only have an email and no other data, you include the used timezone so they can calculate their local time from that themselves.
- Scarblac 5y ago
  To keep all information, you also need to store the timezone that the event originally was. E.g. When comparing temperature charts from different places in different timezones, you may want to show them in a way that "noon local time" is on the same place of the X-axis in both cases. Or more usual: I keep a log of what I do during a day. If I now move to another timezone and want to look at the log, I don't want the times shown in my current timezone. I want the timezone I was in back then.
grey-area 5y ago
All that tells you is the timezone the user was in (or if you're unlucky the timezone the server was in) when the data was recorded. So it's not usually very valuable information. It doesn't tell you anything about the time zone this particular user would want to see it in today, which depends on quite a few factors including where they are and what the timestamp relates to (booking, event, log of past events etc).
- Scarblac 5y ago
  Well, garbage in garbage out, of course. But in applications where it matters, you make sure you know the source timezone where the data enters your system.
  - grey-area 5y ago
    Which applications does it matter for?
    - shpx 5y ago
      This can matter when timezone definitions change, such as when a country decides to start/stop following daylight saving time. If I schedule something for 1 pm 6 months from now, and a transition to/from DST is supposed to happen at some point during those 6 months, and then my country decides to not follow DST anymore or to follow DST year-round, once you update your timezone database and convert your UTC stored time to my timezone, it's going to either be 12 or 2 pm now. This is probably not what users want, unless they scheduled the event to happen a certain time interval after some other event that's not affected by timezones.
      - grey-area 5y ago
        Thanks, I was thinking more about an application that requires it day to day. So a future event made before the time zone transition of a country? That's rare enough that I think a one-off transition plan would be fine. Given the downsides of storing dates with time zones (comparison, confusion etc), it doesn't seem very attractive to me.

BiteCode_dev 5y ago

The debate that started this thread proved my point without needing any effort of my part :)