[HN Gopher] Timezone Bullshit
___________________________________________________________________
Timezone Bullshit
Author : organian
Score : 326 points
Date : 2021-02-10 10:25 UTC (12 hours ago)
(HTM) web link (blog.wesleyac.com)
(TXT) w3m dump (blog.wesleyac.com)
| cfstras wrote:
| The part about "using the text of the invalid timezone" seems to
| be fixed in latest GNU date (8.32): $ TZ=EDT
| gdate Wed Feb 10 13:22:23 UTC 2021 $ gdate --version
| date (GNU coreutils) 8.32 ...
|
| 8.30 (shipped in debian buster) still has the problem.
|
| The BSD version of _date_ shipped with MacOS 10.15 also does not
| seem to have this bug.
| prussian wrote:
| more likely the libc. I have the same version of GNU date using
| glibc and this behavior persists, as I would expect.
| jacobsenscott wrote:
| I cringe every time someone send me an email that says "I can
| meet at 10 PST" no matter what time of the year it is. But what
| can you do.
|
| As far as the unix utilities go, the behavior is non-intuitive
| for sure, but can probably never be changed without breaking
| massive amounts of existing systems. The behavior is also
| reasonable considering the system constraints at the time it was
| written. Consulting an ever changing tz database every time the
| command runs was not an option, and maybe isn't even today.
| jackson1442 wrote:
| > I cringe every time someone send me an email that says "I can
| meet at 10 PST" no matter what time of the year it is.
|
| Why? An average person (read: non-developer) rarely needs to
| think about their timezone, save for when it changes. As a
| human, it seems relatively straightforward to intuitively
| determine whether that person is in DST or not.
|
| If you were a UNIX machine (or a developer providing input to
| one such machine, I guess), it might be more appropriate to ask
| for a response in the Americas/Chicago format or something like
| UTC-0600, but it seems rather coarse to require that everyone
| adhere to your personal timezone standards when interacting
| with you.
|
| Personally, I frequently schedule meetings with clients all
| over the US where their timezone isn't necessarily clear to me,
| so I usually just say something along the lines of "1045am CT,"
| omitting the S/D in its entirety.
| deepsun wrote:
| Is there a way to know which timezone (e.g. America/Phoenix) I'm
| in right now?
|
| I did actually missed a meeting due to that. I was in small city
| in Montana, checked list of these timezones, but didn't know
| which one to choose. So I saw Phoenix has the same time as me,
| and set it at my device.
|
| However, turned out that Montana actually uses America/Denver
| (which is Colorado) as their timezone. Is there a way to know
| that?
| cwmma wrote:
| the general rule of thumb for American Timezones is that
| Arizona is its own special thing and as long as you stay out of
| that state then you're in
| America/{los_angeles|denver|chicago|new_york} for pacific,
| mountain, central, and eastern respectively.
|
| Just stay away from Arizona and American time zones are easy
| and what you did would work.
|
| Arizona is special because it's in mountain time, it doesn't
| observer daylight saving time so half the year it has the same
| time as pacific time except for the Navajo Nation which _does_
| observe daylight saving time but the Hopi Nation which is
| entirely inside the Navajo Nation doesn 't follow daylight
| saving.
|
| edit: picture of the Arizona timezone situation
| https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Ar...
| NoOneNew wrote:
| Tom Scott did a fun video of the general nightmare that timezones
| bring to the dev table: https://youtu.be/-5wpm-gesOY
| sdm wrote:
| > There are actually two timezones that are canonically named
| "CST", and they're 14 hours apart!
|
| Yup. If you say CST do you mean China Standard Time or Central
| Standard Time? The answer will depend on where you live in the
| world. There are others that share the same abbreviation as well.
| But CST is the one that constantly causes trouble in daily life.
| Just say no.
| ycombobreaker wrote:
| I find using the Olson DB names works in real life too--
| everybody understands "9AM Chicago" vs. "9AM Shanghai". Major
| international city names have fewer hash collisions than TZ
| abbreviations.
| messe wrote:
| As a support engineer living in Dublin "IST" is the bane of my
| life.
| javbit wrote:
| I got bit by this when scheduling an interview. It's
| interesting because it's not that much harder to say
| America/Chicago (or just Chicago) but it's just by default I
| tend to say CST, CDT, etc. Started using UTC offsets but not
| many people know those off the top of their heads.
| soco wrote:
| According to Wikipedia there are more than one overlappings:
| https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...
| messe wrote:
| I think BST, CST and IST are the only triple overlaps. I live
| in one and I'm adjacent to another.
| tal8d wrote:
| Many years ago USPS provided a data stream that included every
| sorting machine operation a mail piece went through, the location
| it occurred (zip code), and the local time (sans timezone
| information). That was an absolute nightmare of a project that
| always had a few weekly cases of letters somehow time-traveling.
| Also, I was surprised to learn that there are sort facilities on
| tribal lands - I was not surprised to learn that they elected to
| record time differently from the state that surrounded them.
| xyst wrote:
| On macOS (Catalina-10.15.7), it looks like it is fixed or uses an
| updated version of the libc library mentioned in the article
|
| Expected:
|
| $ TZ=LOL_THIS_DOESNT_EXIST date Sat 10 Jul 2021 12:00:00 AM LOL
|
| Actual:
|
| $ TZ=LOL_THIS_DOESNT_EXIST date Wed Feb 10 17:02:02 UTC 2021
|
| Otherwise I agree with the article. Have told so many co-workers
| that storing your dates in anything other than UTC will bite you
| in the ass later on. Converting it to the relevant time zone for
| display purposes is a trivial operation.
| rini17 wrote:
| Tangentially, is there a standardized format for local time?
| ISO8601 has the same issue.
| tacostakohashi wrote:
| What do you mean? ISO8601 specifies a number of formats. It
| also specifies how to include the timezone/offset, and that not
| mentioning a timezone means local time.
| rini17 wrote:
| So how do I properly serialize a datetime in Europe/Prague
| time zone? As the article explains the use case where "CET"
| nor "CEST" nor fixed timezone offset is sufficient. And my
| actual local time zone is Europe/Bratislava, which may
| eventually differ from Prague.
| eqvinox wrote:
| I think this is out of scope for ISO 8601, especially since
| the "Europe/Bratislava" label is a specific reference to
| the tzdata tables. Another system may use another way of
| specifying the location for the time zone, e.g. GPS
| coordinates. (Though in practice I don't think anyone does
| that; literally _everyone_ uses tzdata.)
|
| The "correct" way is presumably to work with an 8601
| timestamp _without_ time zone and carry the time zone spec
| along in an additional field.
| eyelidlessness wrote:
| Another mistake I've seen is using one timezone code used
| interchangeably with others in the "same" timezone. This is bad
| because different locales have different DST rules, and because
| they have different governing authorities which can and do change
| the rules.
|
| And another still: assuming that all of a state uses the same TZ.
| Quite a few do not! Arizona for instance has several tribal
| timezones which honor DST while the state does not. Nevada has a
| little sliver of mountain time. Michigan has four counties in
| central time. And so on.
|
| This stuff is hard to get right. And it's important. "Just use
| UTC" is often the naive solution but it's not good enough for a
| variety of use cases.
| k_sze wrote:
| When I use the "full" timezone name like "America/New_York", how
| does libc resolve the ambiguity during the extra hour of the
| transition from daylight saving time to standard time?
| Ayesh wrote:
| Tzdb has the date and time that location starts/reverts DST. It
| is updated regularly to keep up with regions changing the time
| zones. It happens frequently than many of us like.
| DavidPeiffer wrote:
| I'm not sure I follow (and this week, timezones and time
| handling are really important for my job, so I really want to
| understand)!
|
| If a user provides a time of 11/7/2021 1:50 AM
| America/New_York, how does the library determine if it's a -5
| or -4 offset given that's when daylight savings time ends? I
| believe that's the ambiguity GP is referring to.
|
| I'm trying to align time across a few systems I work with.
| One provides a GMT time with an offset (clean and useful),
| another system reports timezones and local time, and yet
| another system has no idea when it moves between time zones,
| but reports time based on a single timezone consistently.
|
| Not dealing with multiple timezones in the past, it reminds
| me of Tom Scott's video on handling time and timezones,
| summarized at the end as roughly "Go find someone who built a
| library for handling times, thank them profusely, use their
| open source code, give them credit, and never worry about it
| again."
|
| https://youtu.be/-5wpm-gesOY
| et-al wrote:
| > _If a user provides a time of 11 /7/2021 1:50 AM
| America/New_York, how does the library determine if it's a
| -5 or -4 offset given that's when daylight savings time
| ends?_
|
| Edit: I originally misunderstood your question. Since (in
| the future) 2021-11-07 02:00 is when we change to standard
| time, how does a library know whether to apply a -5 or -4
| offset to 01:50?
|
| The library will need to make assumptions about the inputs
| and it would probably stick with the original offset (one
| should check the source). For a human-facing interface,
| it'd be a good idea to raise the issue.
| k_sze wrote:
| This also reminds me of the post Jon Skeet wrote about
| using UTC: https://codeblog.jonskeet.uk/2019/03/27/storing-
| utc-is-not-a...
|
| Also discussed on HN back in the days:
| https://news.ycombinator.com/item?id=19500640
| twic wrote:
| man mktime on my machine reveals:
|
| > The mktime() function converts a broken-down time structure,
| expressed as local time, to calendar time representation. The
| function ignores the values supplied by the caller in the
| tm_wday and tm_yday fields. The value specified in the tm_isdst
| field informs mktime() whether or not daylight saving time
| (DST) is in effect for the time supplied in the tm structure: a
| positive value means DST is in effect; zero means that DST is
| not in effect; and a negative value means that mktime() should
| (use timezone information and system databases to) attempt to
| determine whether DST is in effect at the specified time.
|
| So, not specified.
|
| POSIX is no clearer about which choice it will make [1]:
|
| > The mktime() function shall convert the broken-down time,
| expressed as local time, in the structure pointed to by
| timeptr, into a time since the Epoch value with the same
| encoding as that of the values returned by time(). The original
| values of the tm_wday and tm_yday components of the structure
| shall be ignored, and the original values of the other
| components shall not be restricted to the ranges described in
| <time.h>.
|
| > A positive or 0 value for tm_isdst shall cause mktime() to
| presume initially that Daylight Savings Time, respectively, is
| or is not in effect for the specified time. A negative value
| for tm_isdst shall cause mktime() to attempt to determine
| whether Daylight Savings Time is in effect for the specified
| time.
|
| > Local timezone information shall be set as though mktime()
| called tzset().
|
| > The relationship between the tm structure (defined in the
| <time.h> header) and the time in seconds since the Epoch is
| that the result shall be as specified in the expression given
| in the definition of seconds since the Epoch (see XBD Seconds
| Since the Epoch) corrected for timezone and any seasonal time
| adjustments, where the names other than tm_yday in the
| structure and in the expression correspond, and the tm_yday
| value used in the expression is the day of the year from 0 to
| 365 inclusive, calculated from the other tm structure members
| specified in <time.h> (excluding tm_wday).
|
| > Upon successful completion, the values of the tm_wday and
| tm_yday components of the structure shall be set appropriately,
| and the other components shall be set to represent the
| specified time since the Epoch, but with their values forced to
| the ranges indicated in the <time.h> entry; the final value of
| tm_mday shall not be set until tm_mon and tm_year are
| determined.
|
| ... but i think the final paragraph implies that the tm_isdst
| field in the input time should at least be set to indicate
| which choice was made!
|
| Java is explicit [2]:
|
| > In most cases, there is only one valid offset for a local
| date-time. In the case of an overlap, where clocks are set
| back, there are two valid offsets. This method uses the earlier
| offset typically corresponding to "summer".
|
| [1]
| https://pubs.opengroup.org/onlinepubs/9699919799/functions/m...
|
| [2]
| https://docs.oracle.com/en/java/javase/11/docs/api/java.base...
| bolle wrote:
| Falsehoods Programmers believe about Time
| https://news.ycombinator.com/item?id=4128208
| 7OVO7 wrote:
| no standards = bullshit
| nelsonenzo wrote:
| I always suspected the Whattimeisitrightnow.com joke on Bojack
| was inspired by a Sys Admin and hollywood writer getting drunk
| together.
|
| Nice blog post.
| qwertox wrote:
| What an important article to read. I've dealt over a decade with
| timezones, and this short article has shown me something new (EDT
| is not unique, gets silently set to UTC).
|
| I am in the habit of using "Country/City" on everything that is
| not UTC, so I never encountered this issue. But it's so good to
| know.
| majewsky wrote:
| Nitpick: "Continent/City".
| jpitz wrote:
| "America" isn't a continent.
| treesprite82 wrote:
| America can be a continent. Definitions vary so sometimes
| it's split into "North America"/"South America", or
| pluralized "Americas".
|
| TZ database includes "America/Santiago" and
| "America/Sao_Paulo" so clearly it means the continent and
| not just the US.
| jpitz wrote:
| "The seven-continent model is usually taught in most
| English-speaking countries including the United States,
| United Kingdom[38] and Australia,[39] and also in China,
| India, Pakistan, the Philippines, and parts of Western
| Europe."
|
| https://en.wikipedia.org/wiki/Continent
|
| Definitions do indeed vary, but that's how I learned it,
| and it would even seem to be the model most often taught.
|
| Which way were you taught?
| c0l0 wrote:
| The problem highlighted here causes one of the few gripes I have
| with PostgreSQL, and its logging capabilities in particular: It
| seems to only support logging time in one single format, which
| does contain a timezone identifier - but using the potentially
| ambiguous shorthand name.
|
| A few moons ago, that led me down a whole new rabbit hole of its
| own that is Golang's time zone parsing capabilities
| (https://github.com/golang/go/issues/9617), which, at least for
| Elastic's filebeat, seem to vary at runtime depending on whether
| or not you have a time zone database available...
|
| Moral of the story: Please just conform to ISO-8601 everywhere.
| de_Selby wrote:
| I'd say the moral is that server side should always be in UTC.
| jnye131 wrote:
| OR.. should they be in TAI?
| https://en.wikipedia.org/wiki/International_Atomic_Time
| zaarn wrote:
| Surprisingly, a bunch of software doesn't like it when you
| setup TAI, if you manage it to begin with.
| FabHK wrote:
| Unless sub-second accuracy is required, I'd be in favour of
| UT1. It doesn't use SI seconds (while TAI and UTC do), but it
| has the advantage that a day has exactly 86400 seconds, so
| you don't ever have to deal with "23:59:60" timestamps.
|
| Summary:
|
| UT1 - noon is when the sun is above you, day has 86400
| seconds (not SI seconds)
|
| TAI - noon drifts away from when the sun is above you, day
| has 86400 SI seconds
|
| UTC - noon is when the sun is above you (+/- 1 second), day
| has 86400+/-1 SI seconds
|
| Difference UT1-TAI: continuously diverging
|
| Difference UT1-UTC: continuously diverging up to less than
| +/-1 second, then discretely jumps back when it gets too big
| (leap seconds)
|
| Difference TAI-UTC: increasing in discrete increments of +/-1
| full second (leap seconds)
| Unklejoe wrote:
| I'd rather just use TAI and never have to worry about
| anything. Let the conversion to UTC be the client's
| problem.
|
| Having the length of a second always be the same is kind of
| important.
| FabHK wrote:
| For logs, fine. But you do deviate more and more from
| what the world is using (as of 2017, TAI is exactly 37
| seconds ahead of UTC, according to Wikipedia)
| outadoc wrote:
| Not true. Say you want to save an event that you know will
| happen on the 14th of July at 15:00 Paris time, in the year
| 2025. Current time zone rules tells you this will be at 13:00
| UTC. Well, if France decides to abolish DST and stick to
| standard time before then, you'll be wrong.
| eqvinox wrote:
| No, they won't be wrong, because the TZ database includes
| historical data & will know that DST was still in effect at
| the time you saved the timestamp.
|
| [Ed. Nevermind, sorry, I see you're referring to a future
| point. My bad. You're right.]
| de_Selby wrote:
| For that use case definitely, though a law change is a bit
| of an edge case.
|
| For stamping times like in a log though UTC should always
| be used server side.
| outadoc wrote:
| Sure! But my point is there's no one true way to do it
| and you always have to think about what you're trying to
| represent and how you're going to use it.
|
| Also, I would argue time manipulation is full of _many_
| "edge cases" like this one, which is why it's so hard.
| It's going to work fine until it doesn't.
| NateEag wrote:
| In some cases, storing times in UTC opens you up to possible
| errors:
|
| https://codeofmatt.com/on-the-timing-of-time-zone-changes/
|
| I think the right thing is to store times with the timezone
| the user wanted when they created the time. You can often use
| defaults or other UX niceties to streamline specifying TZ,
| but not always.
|
| Also, if you'll want to unambiguously know the timestamp's
| exact point in time at some point (like for comparison with
| other dayetimes), you should save the offset from UTC
| alongside the actual datetime. Otherwise, around clock
| changes like "fall back" you cannot tell if you're seeing 2
| AM for the first or second time.
|
| This is the best I've come to trying to piece datetime
| storage together. If someone has better advice, I'd love to
| hear it.
|
| For more of my theory on timezone handling and the sources
| I've used to help me think it through, see
| http://howicode.nateeag.com/dates-and-times.html .
| HideousKojima wrote:
| .NET's DatetimeOffset class does this really well, and
| what's nice is you can access the local system's timezone
| database to convert it to whatever the local time was in
| that timezone for a given date (it's aware of when DST or
| timezone changes occured). I'm sure several other languages
| have similar tools too.
|
| It doesn't solve _every_ conceivable timezone issue, but it
| solves 99% of the problems most developers would have with
| it.
| grenoire wrote:
| Man, as a European this confuses the shit out of me. EST/CST and
| friends are nearly meaningless because I don't even know if the
| time I'm looking at is or supposed to be DST adjusted...
| rbanffy wrote:
| I believe the best move (literally) I ever made was to migrate
| from GMT-3 to (mostly) UTC.
| [deleted]
| ZainRiz wrote:
| If you think that's bad, there are three distinct time zones
| which each go by CST.
|
| And even Central Standard Time is ambiguous
|
| https://www.zainrizvi.io/blog/falsehoods-programmers-believe...
| FabHK wrote:
| Can I just say how grateful I am for good date/time/timezone
| libraries? Ok, this here library may not be a very good example -
| but imagine having to write and maintain all that stuff by
| yourself...
| protomyth wrote:
| Odd, I have been using CST6CDT on my OpenBSD servers. Is this not
| a normal construction?
| prussian wrote:
| you'd have to constantly update your TZ to reflect changing
| transition periods, which you don't even specify. using a
| tzdata file, you get this for free plus proper transitions for
| older dates.
| protomyth wrote:
| Uhm... CST6CDT has zone info just like America/Chicago or
| America/New_York. What am I missing?
| de_Selby wrote:
| > Let's take take a look, using the disastrously bad unix libc
| timezone tools
|
| Are there any more examples of them causing issues to warrant
| being called "disastrously bad"? This post just seems to have one
| example of bad error handling when they the TZ env var is set
| incorrectly.
|
| I'm genuinely interested if they actually are bad since they are
| used a lot.
| bombcar wrote:
| They usually work because people check and notice mistakes.
|
| It gets worse now that you have countries next to each other
| that are out of sync on daylight saving - America/Los Angeles
| doesn't work for those south of the border anymore - but you
| won't notice except two weeks a year.
|
| Strangely I've noticed some systems give you WAY more cities
| than in the standard library - and I'm not sure why. Linode had
| way more options than just America/Chicago but didn't have St
| Paul.
|
| And trying to schedule things in advance across the daylight
| saving time difference is even more confusing.
| tlb wrote:
| Before about 1920, many US cities had their own time. Since
| then, there are far fewer time zones, mostly uniform across
| states, and named after a large city. Similarly in other
| countries. The large version of the database is only needed
| if you're trying to print very old dates.
| Annatar wrote:
| _FACEPALM_
|
| It's not "EST", it's EST5EDT because the string "EST" shows up in
| other time zone designations. Learn time zones, then come back.
| [deleted]
| prussian wrote:
| tzset(3) explains this. GNU is actually sort of bailing the
| author out in the unfortunate cases like America/New_York where
| it ignores you forgot to provide the prepending colon.
|
| In terms of EDT, LOL, etc: again, well explained in the tzset
| manpage. EST works only because it appears the timezone database
| has EST and again, GNU is being helpful and assuming you meant to
| add the prepended colon.
| jwalton wrote:
| Another reason not to use EST/EDT is that they are overspecifying
| the time zone in most cases. If you ask for output in EDT, but
| the date is in December (which is not part of daylight savings
| time) then should the date output be UTC-4 or UTC-5? Technically
| you asked for EDT.
|
| Using EST as a shortcut isn't a good idea, either - most software
| will "know what you mean" and use EST or EDT appropriately...
| except, both The USA and Canada have been toying with the idea of
| dropping daylight savings time, so it's very possible at some
| point in the future that 6:00pm on July 1st will be EDT in
| America/New York, but EST in America/Montreal (or vice versa).
| This is already true for CST - Saskatchewan doesn't use DST. And
| there have been times where one country or another changes the
| start date or end date of DST too, so there's no reason to assume
| those will always be the same between Canada and the US.
| phlo wrote:
| > If you ask for output in EDT, but the date is in December
| (which is not part of daylight savings time) then should the
| date output be UTC-4 or UTC-5?
|
| EST is always UTC-4 and EDT is always UTC-5. Both of these
| exist throughout the year. The only change happening in
| Spring/Autumn is that some places change which time zone they
| currently observe.
|
| This also addresses the second problem that you outlined. As
| long as the query is properly specified (if you want
| information related to a location, use America/New York; if you
| want information related to a time zone, use the time zone),
| you can always get an unambiguous and correct answer.
| dmm wrote:
| To be pedantic EST and EDT are offsets. America/New_York is
| the timezone which consists of multiple offsets that depends
| on the time of year and date mostly determined by the local
| civil authority. For example in 2005, the US extended
| daylight saving time by four weeks. This difference between
| 2004 and 2006 is a part of the timezone.
| emmelaich wrote:
| < EST is always UTC-4
|
| Unfortunately not. Australia also used EST until recently.
| Now they've introduced AEST, but I'm sure there's systems out
| there using EST.
| mikelward wrote:
| When somebody writes EST in summer they mean UTC-4.
| Interpreting that as UTC-5 is almost always wrong.
| kelnos wrote:
| Right, but that's because people are misinformed as to how
| timezones work. EST means UTC-5; people who refer to EST as
| current during the summer are incorrect. Most news outlets
| avoid the problem by just saying "ET" or "Eastern Time",
| which I wish more people would do.
| throw0101a wrote:
| > _EST is always UTC-4 and EDT is always UTC-5._
|
| Except you have those reversed. :)
| kelnos wrote:
| I (living in California) usually use "PST8PDT", which does what
| I want, all year round (for some irrational reason I refuse to
| claim that I live in Los_Angeles[0]). I believe there's also
| "EST5EDT", "CST6CDT", and "MST7MDT" as well.
|
| But agree that this is just a grab bag of confusing garbage.
|
| [0] I suppose if CA does away with DST (or keeps it
| permanently), I will have to change...
| Lvl999Noob wrote:
| On the topic of DST... can you explain why some countries use
| DST? Anytime I look for the reasoning of it, it says that DST
| helps "make better use of daytime" but how? The earth isn't
| gonna say "Damn! These people changed their clocks. I better
| change by rotation and give them more sun time." Whether you
| have DST or not, you still have the same amount of time with
| sunlight in a day.
| snarf21 wrote:
| We need to get rid of DST switches permanently. We should
| stick with DST as most people prefer extra light at night.
| throwaway2245 wrote:
| The excuse usually given is to match up farm work, which is
| dictated by dawn, with general work shift patterns.
|
| However, I recall that farmers are very split on the issue
| when polled - it impacts on their work shifts as well.
| Arubis wrote:
| Source: none, this is my pure supposition and projection.
|
| Power. The sensation of raw power.
|
| By and large, the best way to eliminate DST would be for one
| or more sufficiently powerful lawmakers or political
| executives to say: this is no longer benefiting the public at
| large, and we are going to stop!
|
| These are the folks empowered to change the date on which DST
| transitions (at least stateside). These are also the same
| folks whose careers have been mostly defined by the
| deliberate and incremental accumulation of power into their
| own hands.
|
| If you're wired for that kind of desire for power, the
| ability to tell the entire country: okay, I am changing time!
| It happens on this date! --must be simply _irresistible_. I
| mean: you're literally changing TIME. Hot shit! The entire
| population has to respond! You're changing TIME! Why give
| that up?
|
| While I'm storytelling and presuming, I'll note that this
| needn't be a deliberate, conscious decision; I'm only
| suggesting that the people positioned to change this sort of
| thing are probably naturally wired to resist doing so, and
| may not even be aware of why themselves.
| davchana wrote:
| I am from India, northern part, where there is a lotbof
| variation between sunlight hours throughout the year. Some
| days the sun is out at 6 or before in summer, & in winter its
| some time not out even till 9 or such.
|
| India does not use timezones. Every business, school, office
| who has business hours, use something like Winter Timings
| Summer Timings. Schools & such use 14 Oct to 14 Apr as
| Winter, & other 6 months as summer. My school used to open at
| 6 in summers, & 7:30 or 8 in winters.
|
| Here in US they keep the opening timings same throughout the
| year, but go through this DST shenanigans.
| macintux wrote:
| Just once I'd like to have a time zone discussion on HN that
| doesn't devolve into pages of arguing about daylight saving
| time.
|
| If you search HN you'll find plenty on this topic.
| db48x wrote:
| You'll have a happier life if your dreams are attainable.
| klyrs wrote:
| I mean, you're not wrong... but what else is there to talk
| about?
|
| Fact of the matter is, your preferences depend on where you
| live, your lifestyle, and the amount of time you spend on
| date&time fuckery in code. It's a contentious issue.
| xyzelement wrote:
| You got a bunch of longish replies to your question and I
| can't tell if they covered the simple answer. DST changes the
| question of : is it dark at 7am when I get up or not? is it
| light when I get off work at 5 or not?
|
| It aims to shift the usable daylight hours to correspond with
| human activity.
| jolmg wrote:
| It's interesting how it's easier to change time than to
| change the hours in which we work. I wonder if there's any
| country where the government has enough control over
| working hours to shift those around instead. Instead of
| shifting the clock one hour, we could shift the time we
| start and end work.
|
| It's like DST is the wrong solution to an XY problem.
|
| Thinking practically though, DST is bound to work without
| enforcement, so it has that advantage.
| mikestew wrote:
| _It 's interesting how it's easier to change time than to
| change the hours in which we work._
|
| What with covid/wfh, I have been wondering is this might
| be the push needed to end DST. Because I sure as hell
| have changed the time I work. Dog walk in the dark in
| December because about 4 hours of daylight in Seattle?
| Fuck that, we walk the dogs smack in the middle of the
| day now, we can work when it's dark. Strap on the
| reflective gear, headlamp, and go for a run? Oh, hell no.
| 2 in the afternoon, baby; I'll fix that bug late
| afternoon.
|
| I still get up super early, but instead of getting in
| that run before work, I just work. Then shift that
| running time to when the sun's up. But I speak from the
| position of the privileged tech worker (and one w/o a lot
| of meetings). There are still the DST issues of when
| children stand waiting for the school bus, et. al.
| freeopinion wrote:
| I'd be interested to hear the experience of people in
| China. As I understand it, all of China shares a single
| timezone while neighbors to the north and south are
| spread across five timezones.
|
| Clocks in western China are four hours out of sync with
| their neighbors just over the southern border in
| Pakistan, for example. So do businesses in western China
| open from 1pm to 9pm? Do people eat breakfast at noon?
|
| I'm really curious about that experience.
| wahern wrote:
| https://www.theatlantic.com/china/archive/2013/11/china-
| only...
| ben509 wrote:
| > It's interesting how it's easier to change time than to
| change the hours in which we work.
|
| I think the main pain point would be customers being
| confused as to when companies are open.
|
| This doesn't even work well with smartphones; all the
| calendar apps are hopelessly manual and can't answer
| something like "what are good times to run an errand
| involving steps X, Y, Z."
|
| At _best_ , you can ask it when people are available for
| a meeting and it will show you that everyone important is
| booked solid.
| [deleted]
| [deleted]
| jolmg wrote:
| > I think the main pain point would be customers being
| confused as to when companies are open.
|
| But why would so many people rely on a 1 hour difference
| that this would become a "main pain point"? I don't know
| the working hours of most places I go to. When I really
| want to know, I check Google Maps (or their website).
| Even then, when it's close to opening or closing hours by
| like an hour, I sometimes prefer not to trust it if it'd
| be too problematic for it to be closed after making the
| trip, because it does happen at times that it's
| incorrect. Small shops might not even follow their own
| stamped-on-the-window working hours strictly either.
| filoleg wrote:
| I think one practicality of it that you forget is the
| difficulty for people too, not just for businesses or
| government entities.
|
| For example, people are used to banks always being open
| 9am to 5pm. With the approach you mentioned, it means
| that twice a year they will have to shift it. It means
| you will also have to shift your entire schedule, and
| calendar, and literally everything. Now think about some
| shops and places that will NOT be switching it and decide
| to keep the same hours. Then add-in the fact that some
| shops already change their hours even with the current
| system. For example, I have a daily recurring alarm for
| 7am. Under this proposed system, I will have to manually
| change it twice a year (while now it is done
| automatically due to the entire timezone switching twice
| a year).
|
| You will simply get a logistical nightmare, since
| changing the entire clock is much much simpler than
| shifting each individual little scheduled item in your
| life.
|
| Tl;dr: while i agree that logically your approach of
| shifting individual scheduling items to align with the
| daylight hours makes more logical sense, it makes more
| practical sense to just switch timezones twice a year for
| that purpose.
| jolmg wrote:
| > I have a daily recurring alarm for 7am. Under this
| proposed system, I will have to manually change it twice
| a year (while now it is done automatically due to the
| entire timezone switching twice a year). You will simply
| get a logistical nightmare
|
| At least with respect to updating the alarm, that
| "logistical nightmare" can't be any worse than what we
| had before clocks updated themselves. I still remember
| having to update all clocks manually twice a year. It
| wasn't a big deal. Someone coming in late or missing an
| appointment because they forgot to update a clock
| happened rarely. Maybe it's not the case now, but you
| used to get multiple warnings reminding you to update
| your clocks.
|
| > For example, people are used to banks always being open
| 9am to 5pm. With the approach you mentioned, it means
| that twice a year they will have to shift it. It means
| you will also have to shift your entire schedule, and
| calendar, and literally everything.
|
| With respect to opening and closing hours of banks and
| shops, for those _few_ people that go near opening or
| closing hours even in that time of the year, they 'll
| make the mistake that day and either come back later when
| it's open or otherwise fix their issue that day or at
| least they won't make the same mistake the next day. The
| world wouldn't go up in flames because of this.
| [deleted]
| bjourne wrote:
| > It's interesting how it's easier to change time than to
| change the hours in which we work. I wonder if there's
| any country where the government has enough control over
| working hours to shift those around instead. Instead of
| shifting the clock one hour, we could shift the time we
| start and end work.
|
| Iran used to do that. But for some reason they abandoned
| it and now use "normal" daylight saving time.
| fireattack wrote:
| I still don't get it. During the winter, the daylight hour
| is literally _shorter_ , not just shifted. Shifting one
| hour won't magically make it longer. At best it gives your
| more daylight in one end, while sacrificing the other (and
| more than 1 hour, since again, the total daylight hour is
| shorter). So why bother?
| notJim wrote:
| Because the idea is that sunlight during a particular
| part of the day is more valuable. One reason I've seen
| given (not saying I agree with it) is that if you "move"
| the sunlight to the morning, it means kids won't have to
| wait for the school bus in the dark. Or if you "move" it
| to the afternoon, then there will be a little bit of
| daylight at the end of the day for people working 9-5,
| which might be useful if you want to go for a run or
| something.
| somehnguy wrote:
| >It aims to shift the usable daylight hours to correspond
| with human activity.
|
| But it fails miserably at it.. Here in NYS all winter long
| it gets dark at 5PM. Summer, 9PM.
|
| It's useless and just causes inevitable confusion every
| year.
| jws wrote:
| There's nothing to be done about winter, that is the
| "regular" time and you live in the north. You only get
| the sun above the horizon for 9 hours a day in late
| December.
|
| The summer 9pm is the advantage of daylight savings. You
| get the sun up for 15 hours a day! Norther summer is
| great. Without daylight savings time, you'd get dark at
| 8pm in the summer and have an hour of "wasted" daylight
| before you got up. The "savings" part is to take the
| wasted light while you are sleeping and move it to the
| evening when you can enjoy it.
|
| It does cause confusion though, and having implemented
| daylight savings code there are a bewildering number of
| rules around the world, there are even places that have
| double daylight savings. They shift once, then shift
| again for a two hour offset.
| mabbo wrote:
| Golf courses. Well, okay, this is my wonderful father's half
| serious answer that I love to retell.
|
| The basic idea is that it's easier to convince everyone that
| is actually 5:00pm and time to leave work than it is to
| convince just your boss that you want to start work an hour
| earlier and leave and hour earlier.
|
| This problem is then applied to politicians and other
| powerful people, who want to go golfing after work. If
| there's no DST, the sun will set "earlier" according to the
| clock, and you can't get in a full 18 holes.
|
| So therefore, we change all the clocks so that powerful rich
| people can go golfing.
|
| No other group of people sees any benefits to DST.
| gruez wrote:
| >So therefore, we change all the clocks so that powerful
| rich people can go golfing.
|
| >No other group of people sees any benefits to DST.
|
| Ah yes, because only powerful rich people would benefit
| from extra time in the evening to do outdoor activities.
| mabbo wrote:
| I didn't say it was _right_ , just that I love it.
|
| But truthfully, if our society wants more time in
| daylight after work... let's just leave work earlier. I
| mean, we _are_ doing that, we 're just changing the
| clocks and pretending we aren't. It's dumb.
| BenjiWiebe wrote:
| I like DST and I'm neither rich nor a politician. I could
| be wrong, but I think farmers in general would be pro DST.
| davidgh wrote:
| Since 2018, 13 states in the US passed resolutions to get
| rid of the semi-annual clock changes but also that daylight
| saving time become permanent. Of course, federal law
| doesn't allow them to do such (a state only has the option
| to not observe DST, but not the option to permanently
| observe it).
|
| It probably depends somewhat on latitude and longitude, I
| for one would prefer year round daylight saving time as I
| like the extra evening light in the summer and it's dark
| when my kids leave for school in the winter anyway. I don't
| golf.
|
| The idea of shifting working hours to account for the
| season changes might work in some contexts but not others.
| Sure, if I'm an office "information worker" it's probably
| not a big deal to shift to 7-4 in the summer. But I don't
| think that's going to work for retail, grocery, post
| office, restaurants, gyms, pharmacies, etc. where the
| public isn't going want to constantly adjust to and guess
| at changing opening and closing times.
| mabbo wrote:
| But the public _does_ adjust to changing opening and
| closing times.
|
| We just all change the clocks as well and pretend that we
| didn't. And it's stupid.
| creeble wrote:
| I don't know what you mean by "pretend we didn't". We
| don't pretend anything - we change the clocks and observe
| that change.
| davidgh wrote:
| The previous discussion was talking about adjusting work
| hours as an alternative to daylight saving time. My
| comment is that's not viable a alternative as I don't
| think people want to try to determine if the post office
| closes at 4:00 or 5:00 depending on the date.
| Additionally, if everyone shifts working hours based on
| the time of year, how is that different than just
| changing the clock?
|
| My point is not for or against daylight saving time, just
| that shifting work hours is not a viable alternative to
| it. And if we do get rid of changing clocks, there's a
| decent chunk of the population that has expressed a
| preference for permanent daylight saving time rather than
| standard time.
|
| It's worth nothing that in Russia they experimented with
| permanent daylight time some years ago, and at first it
| was highly supported. However, after some years support
| for it dropped and they moved to permanent standard time.
| However, Russia deals with some unique geographical
| scenarios such as cities with extreme northern latitudes.
| Lvl999Noob wrote:
| Are there really places that don't observe DST and also
| don't change their working hours? Just shift the working
| hours by a few hours when the seasons change. It also gives
| more granularity for the changes. If 1 week in the whole
| season is particularly cold, then change the time again for
| that 1 week.
| CydeWeys wrote:
| > Are there really places that don't observe DST and also
| don't change their working hours?
|
| Huh? I'll flip the question around on you: What places
| are there that don't observe DST that _do_ change working
| hours seasonally, especially in a coordinated way? I
| haven 't heard of any.
| TheRealSteel wrote:
| The liquor store I worked in in Australia had longer
| hours in summer than winter.
| nerdponx wrote:
| Arizona
| SamBam wrote:
| Do Arizona banks and post offices and stuff really change
| their hours in different seasons?
| rwbcxrz wrote:
| Nope. There really isn't much reason to. The winters are
| mild, and Arizona is far enough south that there's still
| a good amount of daylight in the afternoons, at least
| compared to the northern parts of the US.
| ghaff wrote:
| I suspect that at least some of disconnect over DST is
| between people living at 40-50 degrees latitude who have
| short winter days and those living further south.
| GoblinSlayer wrote:
| Normally they match winter sunrise and keep it fixed all
| year long.
| djrogers wrote:
| > Are there really places that don't observe DST and also
| don't change their working hours?
|
| Yes, literally every state/province in North America that
| doesn't observe DST. I don't know what goes on in Europe,
| but nobody in Arizona for example changes the open/close
| time of their barbershop, restaurant, or gas station
| solely due to the time the sun rises...
| Macha wrote:
| I assumed this was the norm in places that don't observe
| DST? Your workday is 9-5, year round, no we're not
| considering the time the sun sets
| bombcar wrote:
| Even with DST here we still have "winter hours" for many
| businesses where it doesn't make sense to be open late
| (10 PM in summer is still light out, 10 PM in winter, sun
| set 5-6 hours ago).
| dmurray wrote:
| The golf courses are closed when it's too dark, but the
| offices aren't. You need to close the office a few hours
| before the golf course, even if your office business
| isn't strongly dependent on the amount of daylight.
| majewsky wrote:
| That sounds like a huge coordination problem. Those
| problems are usually solved by some central entity
| enacting a standard, i.e. government enacting DST.
| [deleted]
| throw0101a wrote:
| The closer one is to the poles, the more the number of hours
| of daylight shifts over the seasons.
|
| So at/near the equator, in a place like Panama, you will get
| roughly 12 hours of daylight in both the December and June
| Solstices.
|
| * https://www.timeanddate.com/sun/panama/panama
|
| Whereas in the Edinburgh you go from having 7 hours of
| daylight in December to over 17 hours in June:
|
| * https://www.timeanddate.com/sun/uk/edinburgh
|
| So people want those 7 hours to be when it's most convenient
| for them.
| wiredfool wrote:
| The worst thing is that the farther north you go, the less
| it matters. In Ireland, DST only really makes a difference
| for a month or so around the change. In the summer, light.
| In the winter, dark.
| [deleted]
| ghaff wrote:
| DST mostly matters between about 35-50 degrees latitude.
| Less than that and the days are similar enough in length
| throughout the year that it doesn't really make sense to
| change clocks. And, as you say, much further north (or
| south) you have more light than you know what to do with
| in the summer and you're probably largely in darkness
| outside of work hours in the winter whatever fiddling you
| do.
| dreamcompiler wrote:
| ..and the latitude where that 17 hours finally grows to 24
| is called the Arctic Circle.
| AnIdiotOnTheNet wrote:
| The infuriating thing is that our solution to this is to
| change the clock instead of just changing our schedules.
| It's completely ridiculous.
| toomanybeersies wrote:
| Easier to get a few computers to automatically change
| their clock twice a year than every human being to change
| their schedule.
| asoneth wrote:
| This. Coordinating a mass schedule change is just an
| alternate implementation of a time shift.
|
| The primary benefit of mass schedule change is that it
| might make (some) programmers' lives easier. The
| disadvantage is that it makes everyone else's lives
| harder as they adapt to schedule shifts.
|
| (Clocks exist to serve people, people don't exist to
| serve clocks.)
| qwertox wrote:
| We shouldn't even adjust our schedules. We should just
| accept the fact that it is going to be dark at different
| times.
|
| Then again, this would be an issue for road workers
| (those who repair highways or other roads) and maybe
| trash collection services. So it begins... Horrible.
| ljm wrote:
| Technically DST _is_ accepting that it's going to be dark
| at different times, and therefore the completely man-made
| thing that is a clock can be changed a bit to reflect
| that.
|
| A perfectly human solution really: work around the shift
| in daylight hours across the year by fiddling with the
| clocks. The whole thing with schedules and timetables is
| a self inflicted problem in a post-industrial society,
| sure, but workarounds are never really meant to be more
| than a bandaid.
| ghaff wrote:
| The problem is that you need to "fiddle with the clocks"
| in a coordinated way. Schools can't shift around starting
| times asynchronously with the many businesses where
| parents work for example.
| davidw wrote:
| Yeah. Any sufficiently coordinated schedule change would
| involve as much headache as clock changes.
| CydeWeys wrote:
| More of a headache, even. Sadly, DST is the only good way
| to have everyone synchronize a schedule change like this.
| ghaff wrote:
| Those who argue for eliminating DST _but_ somehow still
| preserve some form of winter /summer hours are basically
| arguing for eliminating DST and then recreating it
| poorly.
|
| You either do DST or you mostly just pick a timezone and
| stick with it year round.
| CydeWeys wrote:
| I like the latter approach: year-round DST. Not even
| sunlight in the evening is frequently a problem for me,
| but not enough sunlight in the morning isn't.
| creeble wrote:
| People forget that we (the US) actually had year-round
| DST once - in 1974.
|
| But a couple of kids got hit by buses in the morning, and
| there went that experiment:
|
| https://www.mercurynews.com/2016/10/30/the-year-daylight-
| sav...
|
| Edit: got the year wrong!
| ceilingcorner wrote:
| ...no, actually it's extremely logical. Changing clocks
| society wide is far easier than getting every single
| person and company to adjust its schedule.
| Lvl999Noob wrote:
| Perhaps it was easier in the times before the internet.
| Now a consistent timeline should be far more convenient
| than not having to change your habits by a little bit.
|
| Edit: If changing schedule is normalized, then it would
| be just as convenient as changing the clock. In countries
| without DST, if someone started using DST instead of
| changing their own schedule, it would be just as
| difficult.
| kjakm wrote:
| It's even easier post-internet. Your clocks automatically
| change for you now. In the past you had to remember when
| the change occurred and updated all your clocks manually
| - and if you forgot you ended up an hour late/early to
| any Sunday appointment after the change.
| ceilingcorner wrote:
| I don't think anyone other than programmers thinks DST is
| much of an inconvenience. The clock changes twice a year,
| big deal. That's infinitely less complicated than asking
| your boss if you can start earlier, which means the store
| at the subway station will need to be open an hour
| earlier (since its business comes from commuters), which
| means restaurants will need to be open earlier to address
| the lunch crowd, which means your doctor will need to
| schedule appointments earlier, on and on.
| Johnny555 wrote:
| I think it's hugely inconvenient, I have to shift my
| waking and sleeping time by an hour twice a year and it
| takes at least a week to settle into the new schedule,
| and I have at least a half dozen clocks to shift time on,
| including one that needs a ladder.
|
| Without DST why would I need to ask my boss to start an
| hour earlier? I've lived in places without DST and it was
| just fine, I didn't notice or miss any "extra" hour of
| daylight.
| ghaff wrote:
| In all fairness, people like parents with young children,
| pets, etc. find time changes disruptive. That said, there
| are good reasons to shift schedules in mid latitudes and
| daylight saving time is a good way to do that if you
| don't want 4am sunrises in the summer or heading out in
| the pitch black in the winter.
|
| The reality is that if you don't do daylight savings,
| you're not going to have a collective switch in schedules
| and you're going to have to deal with what, for most, is
| sub-optimal sunlight.
|
| Personally, I don't care much now because I mostly set my
| own schedule. But I'd have hated eliminating daylight
| savings when I was on a more fixed schedule.
| GoblinSlayer wrote:
| What's the problem with 4am sunrises?
| ghaff wrote:
| Because most people would prefer the 4am-5am hour of sun
| in the evening after work.
| GoblinSlayer wrote:
| What, morning sunlight is worse than evening sunlight?
| ghaff wrote:
| For many people? Yes. They wake up in time to go to work
| and they do their outdoor recreational activities in the
| evening. Of course, there are morning people who
| appreciate early morning time to go for a run or whatever
| but I'm willing to bet that most people prefer their
| sunlight after work.
| xboxnolifes wrote:
| I prefer the sun out when I'm awake.
| GoblinSlayer wrote:
| Yes? The sun is out in the morning for sure.
| freeopinion wrote:
| Then get off work at 3am?
| u678u wrote:
| If they find time changes disruptive, changing schedules
| instead of time is going to be equally disruptive.
| ghaff wrote:
| Sure. My assumption is that absent formal time changes,
| schedules _won 't_ change and people will just live with
| what, for many, is sub-optimal schedules with respect to
| sunlight.
| icoder wrote:
| So then you're back to square one right? Where
| (apparently) the preference was given to DST (with its
| downsides), above sub-optimal schedules.
|
| (Edit: Combining both your replies I think that may
| actually be your point)
| ghaff wrote:
| My preference is definitely to slant towards evening
| sunlight, so DST year round. (I actually live somewhere
| that should really be in the next timezone east anyway.)
| Though I'm at least somewhat sympathetic to people who
| don't want kids to be waiting for school buses or
| otherwise heading to school in pitch darkness in the
| winter.
| mindslight wrote:
| > _I 'm at least somewhat sympathetic to people who don't
| want kids to be waiting for school buses or otherwise
| heading to school in pitch darkness in the winter._
|
| That's _another_ problem that needs to be fixed on its
| own, by moving the school schedules back an hour or two
| and making older grades start later instead of earlier.
| There has been enough research showing that the current
| schedule is horrible for learning.
| bluefirebrand wrote:
| > I don't think anyone other than programmers thinks DST
| is much of an inconvenience. The clock changes twice a
| year, big deal
|
| Everyone, and I mean everyone, I talk to about DST hates
| DST and wants it gone. It's definitely not just
| programmers who dislike it.
| toyg wrote:
| _> I don't think anyone other than programmers thinks DST
| is much of an inconvenience._
|
| I don't think anyone other than programmers thinks DST is
| not a huge pain in the ass.
|
| Twice a year your bodyclock gets screwed up and you risk
| getting to work at the wrong time; once a year you even
| get a shorter night of sleep.
|
| In Europe (hardly "programmer's country"), it took very
| simple polling to discover that DST was hugely unpopular.
| The population at large simply does not benefit, it was
| introduced for the good of industry and we're largely
| leaving behind that world. Good riddance.
| BrandoElFollito wrote:
| To be fair, the polling went largly unnoticed (at least
| in France). I discovered it by chance in the middle of
| summer, shortly before it got closed.
|
| Then the results were published and a few people were
| pissed off for not having been informed.
|
| OTOH, it would have had been a discussion for 20 years
| otherwise.
|
| I am happy we just have one tole shift left (to move to
| summer time, yay for me because I am on the western edge
| of a timezone)
| remram wrote:
| Your argument sounds very similar to the "let's abolish
| timezones" argument so let me post this again:
| https://qntm.org/abolish
|
| Changing your schedule works for you and your boss, but
| does not let people in other parts of the world know when
| they can reach you. Officially shifting _something_ is
| necessary, and then you might as well have timezones.
| SamBam wrote:
| I find it insane that there are otherwise-smart people in
| the world that want to abolish time zones. For example,
| this NY Times article. [1]
|
| In includes the most bizarre history:
|
| > A century and a half ago, time zones didn't exist. They
| were a consequence of the invention of railroads.
|
| ... and goes on to describe that it's suddenly so
| confusing and laughable that when it was 7:00 in New
| York, it would now be 8:00 in Chicago and 5:00 in San
| Francisco.
|
| But what on Earth did the writer think the time was in
| San Francisco _before_ there were time zones?
|
| Before there were time zones, everyone synchronized to
| local noon. The result was much more fine-grained "time
| zones." What time zones did was to actually flatten those
| difference, leading to _fewer_ time zones, because now
| suddenly the time in Maine was the same as the time in
| Michigan, despite being at completely different
| longitudes.
|
| 1.
| https://www.nytimes.com/2016/11/06/opinion/sunday/time-
| to-du...
| amalcon wrote:
| For some evidence of this, consider that sundials have
| existed since about 1500 BCE. The existence of such a
| device easily disproves the notion that the "current
| time" was ever the same globally. Even mechanical clocks
| would obviously need to be set such that they would agree
| with a sundial, or the reading of the mechanical clock
| would be useless in a world where others are using
| sundials.
| WorldMaker wrote:
| Some extended timezone databases even have tried to
| collect historic city timezones from before the
| railroads, most often to the nearest 15 minute offset,
| but sometimes even minute specific offsets. It's
| interesting to explore those.
|
| On that Michigan versus Maine thing, as someone in a city
| that historically was -0045 from its current timezone, I
| feel it interesting to point out that DST is closer to
| local noon than "Standard Time" in the city, versus that
| cities that define the other edge of the time zone and
| have local noon closer to Standard Time noon. (Our hour-
| wide time zones make the question of DST versus Standard
| Time much more complex than just picking one or the
| other, when talking about abolishing DST or standardizing
| only on DST.)
| inglor_cz wrote:
| > The result was much more fine-grained "time zones."
|
| That is true, but it did not bother anyone, because fast
| long-distance communication either did not exist or was
| very limited (e.g. smoke signals) and syncing of clocks
| wasn't necessary in everyday activities; for a medieval
| person, the idea that clocks in Vienna and Prague MUST be
| synchronized would be as strange as for us the idea that
| everyone in the same city should have their breakfast at
| the same time. It just did not serve any obvious purpose.
|
| There are only two exceptions I can think of.
|
| a) people doing astrological horoscopes for someone who
| was born in a different place (a big thing among some
| nobility and royalty) would probably be bothered a bit by
| the time difference,
|
| b) armies trying to converge on the same target at the
| same moment.
| GoblinSlayer wrote:
| People in other parts of the world can reach me at any
| time by email, during the work hours of the email server.
| remram wrote:
| If that is how everyone at your company feel, you don't
| need a schedule at all (or even a clock).
| GoblinSlayer wrote:
| It's just the best way of contact, if people know
| anything else, they can use it, but even in one building
| it's impossible to know who is on vacation, who is fired,
| who is on lunch, who is on a smoking break, who is off on
| an errand, who left a little earlier, who is busy at a
| meeting, who is just busy.
| [deleted]
| scbrg wrote:
| It's a while since I read that article, so I may forget
| some details, but I do recall that I found it pretty
| stupid. It somehow assumes that it would be harder to
| find out what the regular working hours are in a country
| are than it is to find out what time it is in that
| country, possibly _in addition to_ what the regular
| working hours are.
|
| If Google today tells me, "It's now 5PM in Singapore",
| with no time zones it could just as easily tell me
| "Regular working hours in Singapore are 12-20".
|
| OK, so that's two numbers to remember rather than one,
| but _come on_. Thing is, what a certain time means varies
| wildly country to country, and from person to person
| anyway. My Swedish friends eat dinner at 17:30. My
| friends in southern Europe eat dinner at ~22:00.
|
| Unless I know who I'm calling, and their regular hours I
| have no idea if it's OK to give them a call at, say,
| 07:00 or 22:00. So I need extra information about them
| _anyway_ - and that information wouldn 't be harder to
| package in a world lacking time zones. In fact, it would
| be easier, since it'd contain only one element (times
| available) rather than two (times available plus
| timezone).
| blueblisters wrote:
| Fine, let's have separate working hours for every region.
| Now, how do you determine what longitudes share working
| hours?
| scbrg wrote:
| I don't see how the question is relevant. I'm generally
| not communicating with collections of longitudes. I'm
| communicating with people. They can tell me what their
| working hours are.
|
| The point is that they _already have to_ , since working
| hours are, in fact, _not_ identical between neither
| regions nor people within a region.
|
| That said, I'm not saying that we should abolish time
| zones. I'm just saying that that article is stupid and
| fighting a straw man.
| [deleted]
| fishywang wrote:
| >than getting every single person and company to adjust
| its schedule
|
| but by using DST we are just pretending that we didn't
| ask people/companies to adjust their schedules. in
| reality they did, just the "clock" stayed the same.
| dhimes wrote:
| Exactly. Changing our clocks _is_ changing our schedules,
| the easy way.
| kukx wrote:
| Yes, it is similar to how creating inflation by the
| government is just a way to tax poor and the middle
| class, without actually rising taxes.
| yen223 wrote:
| We should embrace this pragmatic approach. We can solve
| climate change by collectively shifting our thermometers
| down a few degrees!
| m463 wrote:
| BST - Beach Standard Temp
|
| or maybe
|
| FST - Florida Standard Temp / Florida Submerged Temp
| asoneth wrote:
| The goal makes sense but our current DST implementation of
| a sixty-minute jump twice a year seems unnecessarily large
| and disruptive. (And not just dealing with kids -- traffic
| accidents and heart attacks spike after.) Whereas if there
| was a way to coordinate a daily shift it would be less than
| a minute.
|
| It reminds me of when I'm camping. I usually fall into a
| dawn-based time system: Wake up around ~dawn, eat breakfast
| ~d+2h, lunch ~d+6h, dinner ~d+12h, bed down ~d+16h. You
| maximize daylight this way but the main problem is that you
| end up drifting relative to everyone else and if you want
| to rely on a standard watch to keep your schedule it
| requires some mental math.
|
| I'd love to figure out how to use a combination of dawn-
| based time system for my daily routines plus UTC for remote
| collaboration.
| gumby wrote:
| It's a technology path dependence issue.
|
| When towns had public mechanical clocks they were
| typically frequently adjusted (even daily) so that noon
| was when the sun was directly overhead.
|
| Once railroads were developed their schedules were a mess
| since each time had to be in the time of the specific
| station. So the railroads got time zones introduced.
|
| Then when the move for DST came around it had to be
| something easy to calculate, thus a one hour shift. Sort
| of like the Dow Jones: something that could be easily
| calculated by hand.
| [deleted]
| XorNot wrote:
| For the same reason that work from home turns out to be
| viable for a huge number of people, and the main reason
| office's are as big as they are is because middle managers
| don't believe work happens if they don't watch someone sit in
| an office chair.
|
| There's no possible way businesses are going to adjust their
| hours twice yearly to let employees get more sunshine, but
| DST does that effectively by ensuring official timekeeping
| gets moved about on them.
| bombcar wrote:
| The even dirtier secret is that NOBODY KNOWS if work is
| getting done because often the work is pointless or ill-
| defined.
| GoblinSlayer wrote:
| What is the point of sunshine if you sit in a box all day?
| You get equally zero amount of it during summer as well as
| winter.
| KineticLensman wrote:
| > Whether you have DST or not, you still have the same amount
| of time with sunlight in a day
|
| Yes, but you can better align the available light with things
| like commutes and school hours - so that people commute in
| light instead of the dark, for example.
| BjoernKW wrote:
| Because of the unfortunately still common 9-to-5 work
| schedule.
| kenniskrag wrote:
| > toying with the idea of dropping daylight
|
| Europeans turn back clocks for daylight saving, perhaps for
| last time. source: https://www.dw.com/en/europeans-turn-back-
| clocks-for-dayligh...
| Hamuko wrote:
| The EU DST debacle has been such a shitshow that I have
| trouble believing the words "perhaps for last time". And now
| with COVID-19, I haven't seen anyone actually focus on
| implementing the damn thing.
| kenniskrag wrote:
| What do you have to implement?
| marcosdumay wrote:
| Brazil spent 3 years talking to everybody, publishing the
| change, and making sure everybody was on the same page.
| Yet, all the companies providing software got it wrong at
| least once (some more than 3 times). The only software
| that got it right were community based FOSS distributions
| (not raspbmc... that got me).
|
| At least all the institutions got it right, so it was
| enough to announce "Windows|Red Hat|iOS|Android|whatever
| is wrong today, ignore it and use some other clock".
| datejfktn wrote:
| For once pretty much no one is aware of this supposed
| change. There was like a couple of articles on the day it
| was voted and that's it.
|
| This will 100% not happen, it's another one of those
| things that the EU parliament votes that everyone
| ignores, and it's perfect ammunition for those
| complaining that it makes laws without popular
| consultation.
|
| Trying to go forward with this change will generate
| massive anti EU backlash.
|
| And then you have the UK problem. Having variable time
| offsets between EU and UK would add yet another layer of
| disruption on top of Brexit.
| kjakm wrote:
| >> And then you have the UK problem. Having variable time
| offsets between EU and UK would add yet another layer of
| disruption on top of Brexit.
|
| It's worse than just EU/UK offset. You would have
| Northern Ireland and the Republic of Ireland in different
| timezones.
| Macha wrote:
| Portugal and Spain manage it, but it would be extremely
| contentius among around half of the NI community.
| iso1631 wrote:
| > For once pretty much no one is aware of this supposed
| change
|
| The consultation had 4.6 million responses.
|
| > Having variable time offsets between EU and UK would
| add yet another layer of disruption on top of Brexit.
|
| So?
| iggldiggl wrote:
| > The consultation had 4.6 million responses.
|
| A disproportionate amount of which were from Germany (2/3
| of the responses, even though Germany only is only ~ 16 %
| of the EU-population pre-Brexit).
| Hamuko wrote:
| > _it makes laws without popular consultation_
|
| That's not accurate.
|
| > _This online consultation, which ran from 4 July to 16
| August 2018, received 4.6 million responses from all 28
| Member States, the highest number of responses ever
| received in any Commission public consultation. According
| to the preliminary results (see annex), 84% of
| respondents are in favour of putting an end to the bi-
| annual clock change._
| datejfktn wrote:
| Selection effect. Those who really cared about this
| commented.
|
| But what about the 99% rest of population? It's a mistake
| thinking that because they dont realllly care they will
| accept either way.
|
| Resistance to change is huge, especially when it plays
| into the narrative "Bruxelles demanded it"
|
| And what I meant by lack of popular consultation is that
| if you go on EU streets and ask about this change 95% of
| people will have no idea what you are talking about.
| iggldiggl wrote:
| > Selection effect. Those who really cared about this
| commented.
|
| And a disproportionate proportion of those (more than two
| thirds) were from Germany, were that topic was an
| especially hot issue for some reason or other.
| majewsky wrote:
| No representative democracy is asking the electorate to
| vote on each and every bill. It defeats the purpose of
| having a parliament in the first place.
| datejfktn wrote:
| I agree with you.
|
| I was just pointing out that it's wrong to say this this
| decision had ample consultation, because overwhelmingly
| the population is not aware of it.
| disgruntledphd2 wrote:
| And almost all the respondents were German (apparently
| this is a big deal in Germany).
| corty wrote:
| The EU is currently one timezone for most of its area,
| the whole continent excluding Portugal (edit: and
| Finland, Greece, Baltic states) has the same timezone.
| But actually it should be 3 or 4 timezones if you want to
| be close to solar time. Also, there are people who would
| prefer having solar zone time +1 (so e.g. UTC+2 in
| Germany instead of UTC+1). The EU decided to chicken out
| and let the members decide for themselves. So now each
| country has to decide which timezone it would like to
| implement, and of course if a neighbour does it
| differently, you also got yourself a timezone boundary at
| your border, which people dislike. So now all the
| politicians are caught in a state of indecision, keeping
| the status quo.
| Hamuko wrote:
| > _The EU is currently one timezone for most of its area,
| the whole continent excluding Portugal has the same
| timezone._
|
| That's definitely not accurate.
| corty wrote:
| Oh, you are right, sorry. The Baltic states, Finland and
| Greece are UTC+2/3
| throw0101a wrote:
| A good portion of the EU is in CET when they probably
| shouldn't be when it comes to solar time:
|
| * https://en.wikipedia.org/wiki/Time_in_Europe
|
| France should probably, AFAICT, be in WET (like the UK)
| and Spain definitely should be. Solar time offsets are
| quite off for them:
|
| * http://blog.poormansmath.net/how-much-is-time-wrong-
| around-t...
|
| * https://github.com/stefano-maggiolo/solar-time-vs-
| standard-t...
|
| * https://24timezones.com/world-time-zones#toc-0
| kevincox wrote:
| I hope that we can stop trying to sync noon to the local
| sun at some point. I think it made sense when
| communicating over distances was hard and rare. In that
| case giving local time some meaning (ex: "People tend to
| wake up around 8") had some value. However now that
| communicating with people around the word is commonplace
| I think that benefit is outweighed by the value of
| knowing what time people are talking about. Because if
| you try to schedule something before I want to wake up it
| is incredibly obvious to me. However if we mess up the
| timezone math by and hour no one will notice unless they
| think to explicitly check.
|
| The only real downside I see is that if the day number
| changes during your "day" it could be confusing. However
| I think we will quickly learn to deal with it (overnight
| shifts have been a thing forever and doctors seem to
| manage). Plus we already have a weaker form of this when
| we are talking about late-night activities so I think we
| will figure it out.
| throw0101a wrote:
| > _I hope that we can stop trying to sync noon to the
| local sun at some point._
|
| Humans have circadian rhythms that have health effects:
|
| * https://en.wikipedia.org/wiki/Chronobiology
|
| See my comment linking to various position papers of the
| scientists who study in this field:
|
| * https://news.ycombinator.com/item?id=26088541
|
| They generally want to get rid of DST completely and
| stick with Standard ("winter") Time all year round. (I
| don't know enough to gainsay them.)
| kevincox wrote:
| I'm not saying that we shouldn't sync our schedules to
| the sun, I'm saying that we should sync time to the sun.
|
| So in Toronto I can wake up at 12:00 and in London people
| can wake up at 8:00. It just changes the number on the
| clock.
| bilekas wrote:
| IE use DST also fyi.
|
| > The EU decided to chicken out and let the members
| decide for themselves
|
| There are reasons the EU doesn't just enforce timeZones
| across its members.. So this is a 'strange' comment that
| bothered me.
| corty wrote:
| I didn't mean to say the EU should enforce a timezone.
| The EU didn't get involved at all after the decision to
| get rid of DST. Not even by providing guidance or
| suggestions for the new timezone layout. Usually when
| there is something to be decided, there is a EU summit or
| work group. But they didn't even do that.
| leokennis wrote:
| It will not happen. The science is overwhelming that having
| one timezone all year long is worse for people, and switching
| the clock back and forth twice a years is a minor nuisance at
| most.
|
| The EU's "Ban DST" is the same populist bullshit as Trumps
| "inject Windex to cure COVID". Based on nothing and ignorant
| at best.
|
| And the cherry on top is, if you ask the EU if they want to
| receive a no strings attached gift of EUR10.000.000.000.000
| or EUR11.000.000.000.000, it would still take them 20 years
| to decide. No way they will ever reach consensus on DST.
| iso1631 wrote:
| > The science is overwhelming that having one timezone all
| year long is worse for people,
|
| Well the majority of people, countries, and square-
| kilometres of land doesn't have daylight saving so you'll
| have to do better than that.
|
| At _some_ latitudes with _some_ social norms (regarding
| things like school start times) DST is beneficial. In
| others it 's not. There are no absolutes here.
| etripe wrote:
| If the science is overwhelming, do you have a source? If
| not, what are the downsides to having the same timezone all
| year?
| kenniskrag wrote:
| Never heard about windex. Now I know.
| throw0101a wrote:
| [Some links that I've posted the last few times DST has
| come up:]
|
| The folks who study this:
|
| * https://en.wikipedia.org/wiki/Chronobiology
|
| Seem to have come to a consensus that if we're going to
| get rid of DST, then health-wise it is best to have
| Standard Time year-round:
|
| > _As an international organization of scientists
| dedicated to studying circadian and other biological
| rhythms, the Society for Research on Biological Rhythms
| (SRBR) engaged experts in the field to write a Position
| Paper on the consequences of choosing to live on DST or
| Standard Time (ST). The authors take the position that,
| based on comparisons of large populations living in DST
| or ST or on western versus eastern edges of time zones,
| the advantages of permanent ST outweigh switching to DST
| annually or permanently._
|
| * https://journals.sagepub.com/doi/full/10.1177/074873041
| 98541...
|
| For a longer-read, referencing quite a bit of academic
| literature, but a conclusionary snippet:
|
| > _In summary, the scientific literature strongly argues
| against the switching between DST and Standard Time and
| even more so against adopting DST permanently. The latter
| would exaggerate all the effects described above /beyond/
| the simple extension of DST from approximately 8
| months/year to 12 months/year (depending on country)
| since /body clocks/ are generally even later during
| winter than during the long photoperiods of summer (with
| DST) (Kantermann et al., 2007; Hadlow et al., 2014, 2018;
| Hashizaki et al., 2018). Perennial DST increases SJL
| prevalence even more, as described above._
|
| * https://www.frontiersin.org/articles/10.3389/fphys.2019
| .0094...
|
| Other position papers that I've dug up over the years
| when curiosity got the better of me:
|
| > _Society for Research on Biological Rhythms (SRBR) is
| dedicated to advancing rigorous, peer-reviewed science
| and evidence-based policies related to sleep and
| circadian biology._
|
| * https://srbr.org/advocacy/daylight-saving-time-
| presskit/
|
| * (refs, with pro and con): https://srbr.org/wp-
| content/uploads/2020/09/DST-References-S...
|
| European Sleep Research Society:
|
| * https://esrs.eu/wp-
| content/uploads/2019/03/To_the_EU_Commiss...
|
| Canadian Society for Chronobiology:
|
| * https://www.theglobeandmail.com/opinion/article-turn-
| back-th...
|
| * https://twitter.com/ChronobioCanada/status/119063209659
| 69264...
|
| American Academy of Sleep Medicine (with 36 footnotes if
| you want to dig further):
|
| * https://jcsm.aasm.org/doi/10.5664/jcsm.8780
|
| * https://doi.org/10.5664/jcsm.8780
|
| The Centre for Chronobiology, based at the Psychiatric
| University Hospital (University of Basel):
|
| * http://www.chronobiology.ch/wp-
| content/uploads/2019/08/JBR-D...
|
| * http://www.chronobiology.ch
|
| (Personally, I'm just going to trust the experts on this
| as I don't have the energy to go digging in things. A
| quick cursory Google/DDG search is enough for me.)
| iso1631 wrote:
| The sun rises in Singapore between 0655 and 0715
| depending on the time of the year. How would changing the
| clock help at all?
| throw0101a wrote:
| It wouldn't, as it gets ~12 hours at both solstices:
|
| * https://www.timeanddate.com/sun/singapore/singapore
|
| DST is mostly for countries closer to the poles. See my
| other comment:
|
| * https://news.ycombinator.com/item?id=26088383
| jmgao wrote:
| > both The USA and Canada have been toying with the idea of
| dropping daylight savings time
|
| Individual states are toying with the idea as well [1], which
| presents a problem if one of the tzdata locations decides to
| change its rules. You're screwed no matter what you choose to
| do. :-(
|
| 1: https://www.syracuse.com/state/2020/11/state-senator-
| introdu...
| siculars wrote:
| They already do. See Arizona.
| 1-more wrote:
| ...and then see Navajo reservation in there, and then see
| the Hopi reservation inside of that!
| Izkata wrote:
| It gets worse: DST in Indiana has to be handled on a per-
| county basis for anything prior to 2006.
|
| https://en.m.wikipedia.org/wiki/Time_in_Indiana
| sschueller wrote:
| I'm still hoping .beat time[1] will catch on but I have been
| waiting since 1998... I even made a watch-face for my smartwatch
| showing .beats
|
| [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time
| throwaway2245 wrote:
| I'm guessing (from your name and enthusiasm) that you live in a
| place where 0 approximately corresponds to midnight? :)
| eCa wrote:
| It would be more fair to split a week into 6000 parts, that
| way everyone would have midnight at strange "hours" but on
| different days.
| sschueller wrote:
| Lunch at @500...
| joquarky wrote:
| Another alternative is to base time on the current longitude of
| the solar meridian.
| phoronixrly wrote:
| > Let's take take a look, using the disastrously bad unix libc
| timezone tools
|
| It seems to me that the author did not initially read the
| documentation they linked to
| (https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...)
| and is now complaining in an annoying and entitled manner.
| biggerfisch wrote:
| Not defending/attacking the phrase "disastrously bad", but I'm
| not sure its a fair argument to say "the docs explain it", if
| the behavior isn't what a "reasonable" person would expect.
| Writing software that deletes your files (when you expect, say,
| the weather report) isn't excused if they write in the docs "oh
| this weather software randomly deletes files for no reason".
|
| In this specific case though, even those docs do not explain
| what happens if the value is "invalid"!
| steerablesafe wrote:
| It's absolutely right to criticize insane behavior even if said
| behavior is documented. LOL "helpfully" being substituted to
| the output is absolutely insane.
| phaemon wrote:
| No it isn't. If you tell your computer that the timezone your
| machine is set to is called "LOL", then _of course_ that 's
| what it should report. What else would it do?
|
| It truncated the name because of the underscores, but you can
| do `TZ=somerandomthing date` to see it just reports what you
| say it is.
| steerablesafe wrote:
| Various behaviors when requesting time in a non-existent
| timezone:
|
| sane: report an error in some hard to ignore form
|
| less sane: ignore the provided timezone, display the time
| in UTC and properly mark it with "UTC"
|
| insane: ignore the provided timezone, display the time in
| UTC, but then mark it with the prefix of the provided
| timezone anyway.
|
| I don't care how well documented the insane behavior is,
| it's still insane.
| phaemon wrote:
| It didn't display the time in UTC, it displayed the time
| in timezone LOL. It happened to be the same as UTC
| because no offset was specified. It knew it was timezone
| LOL because that's what the TZ variable was set to.
|
| If you set your machine to something weird, then expect
| the utility that reports on those settings to report the
| weird settings you set.
| treesprite82 wrote:
| > If you tell your computer that the timezone your machine
| is set to is called "LOL", then of course that's what it
| should report. What else would it do?
|
| If `TZ=EST date` adjusts the offset to EST, then a
| reasonable person would expect `TZ=EDT date` to either
| adjust the offset to EDT, or fail noisily if it's not aware
| of that offset code.
|
| At a skim through the documentation I don't see anything
| warning about it's current behaviour.
| phaemon wrote:
| > or fail noisily if it's not aware of that offset code.
|
| But it is aware of it! You just told it, using the TZ
| variable, what EDT is. It's a timezone called EDT, with
| no offset from UTC!
|
| If you wanted an offset, you should have written
| `TZ=EDT+4 date`
| steerablesafe wrote:
| why doesn't this work the same way for 'EST' then? You
| don't specify offset so it should just display in UTC as
| well, right?
| phaemon wrote:
| Because it has _additional_ information in a file in `
| /usr/share/zoneinfo`.
|
| But you can still define a brand new timezone with the TZ
| variable. Perhaps you want to argue that you _shouldn 't_
| be able to, but that's what it's for, as the document
| linked above clearly states.
| treesprite82 wrote:
| If I'm understanding the examples, it looks like (in
| general) commands such as `TZ=EST date` work as expected
| (i.e. you can set offset just using the offset code).
|
| > But it is aware of it! You just told it
|
| The user didn't intend to. Defining a new offset code
| should be explicit, not a silent fall-back when it's
| unable to find EDT.
| phaemon wrote:
| > The user didn't intend to.
|
| Well, they should have read the docs. They clearly show
| examples of how to define a timezone right there. It
| isn't a fallback, it's what TZ is for.
|
| Edit: perhaps `date` should have a `-z --zoneinfo`
| option, in which you could specify a timezone by file and
| it would fail if the file did not exist. This would fix
| the issue and avoid breaking existing scripts.
| treesprite82 wrote:
| > Well, they should have read the docs
|
| You can say that about any bad design choice, and in this
| case I'd argue that the linked docs don't even agree with
| the behaviour. The syntax given by the docs for creating
| a new timezone requires explicitly specifying an offset
| (then optional stuff like daylight savings).
|
| The quirk may be documented elsewhere, but before getting
| caught out by it the average user has no reason to be
| searching through multiple sources of documentation for
| an oddity they don't yet know exists.
|
| > It isn't a fallback, it's what TZ is for.
|
| If I'm understanding, `TZ=EDT` will search for an "EDT"
| timezone in its database, fail, then instead silently
| default to creating a new timezone with 0:00 offset.
| That's pretty much how I'd define a fall-back.
| steerablesafe wrote:
| Let's pick apart that documentation and the actual behavior,
| shall we?
|
| By the documentation "EST", "EDT" and "America/Los_Angeles" are
| not valid TZ environment variable values, as none of them
| matches any of the formats. _offset_ doesn 't seem to be
| optional, and within _offset_ hours are not optional.
|
| Ok, maybe it is too pedantic, a permissive implementation can
| interpret no offset as 0, right? But that's not what happens
| here. The implementation looks up the timezone by the provided
| name somewhere, and only when it doesn't find it it falls back
| to 0 as an offset.
|
| This lookup behavior doesn't seem to be documented on that
| page. It's not described in the GNU date man page either even
| though it uses TZ='America/Los_Angeles' as an example.
| prussian wrote:
| tzset manpage for glibc explains this:
| If the file specification filespec is omitted, or its value
| cannot be interpreted, then Coordi- nated
| Universal Time (UTC) is used. If filespec is given, it
| specifies another tzfile(5)-format file to read
| the timezone information from. If filespec does not begin
| with a '/', the file specification is relative to
| the system timezone directory. If the colon is omitted each
| of the above TZ formats will be tried.
| ggm wrote:
| The other side of this is people assuming sydney time is brisbane
| or adelaide time, because they have limited experiental knowledge
| of a continent. we're well trained with mountain/central/eastern
| and Hawaii but we sometimes forget that LA is not next door to
| Chicago, I mean how far can it be?
|
| Well.. Brisbane is not Sydney time. half the year we're 1 hour
| offset. AEST is not AEDT.
| juddgaddie wrote:
| 'There is no good reason to use short timezone codes like EST,
| CST, PST -- doing so will only bring you pain. Either use the
| tzdb name like America/New_York, or use an offset from UTC,
| depending on what you want.'
|
| All you need to read/remember is this, this applies everywhere
| not just with date.
| arminiusreturns wrote:
| The problem is peoples fascination with the S in the timezones,
| if you remove the S and the timezone equates to the proper,
| daylight savings adjusted +/- timezone according to the tz db.
| So instead of EST,CST,PST, use ET,CT,PT. For example ET
| equating to America/New_York, or as I prefer, US/Eastern.
| Traditional posix such as EST5EDT can have data gaps which
| cause issues that the tz db make up for, so in general:
|
| _Just use UTC for most things._
|
| As with all things time, I'm no expert, and could be wrong
| about something. If you are, please correct me!
| HideousKojima wrote:
| >As with all things time, I'm no expert, and could be wrong
| about something. If you are, please correct me!
|
| Easy example that I have to deal with semi-regularly since I
| live and work in Mountain Time: Arizona. Arizona is under
| Mountain Time, but does not observe Daylight Savings. So
| America/Phoenix would work fine (and America/Denver for the
| rest of the Mountain Time zone) but simply using MT would
| not.
|
| To complicate matters even more is that the Navajo
| reservation (which is partially in Arizona) observes DST, but
| the Hopi Reservation (also in Arizona, but completely
| surrounded by the Navajo Reservation) does not.
| jonathanberger wrote:
| Unfortunately the statement is not true. One good reason to use
| short timezone codes like EST, CST, PST is that most people
| prefer them.
|
| One of the first surprising things you learn after launching a
| timezone conversion website
| https://news.ycombinator.com/item?id=1133613 is that one of the
| top feature requests is to display short timezone codes.
| Spivak wrote:
| And people prefer them because I have known since I was like
| 4 that I'm on Eastern time but have exactly zero idea what my
| UTC offset is off the top of my head. And also because I
| observe daylight savings EST changes automatically for me
| while I have to remember whether I'm in DST to know my UTC
| offset.
| Tepix wrote:
| It's not just timezones names that are bullshit (they are!), the
| whole calendar is dumb.
|
| Ideally the world should switch to an "earth calendar" where the
| year begins on the shortest day (currently Dec 21st for 90% of
| the population) and there are four yearly planet-wide holidays:
|
| 1. northern solstice
|
| 2. southern solstice
|
| 3. northward equinox
|
| 4. southward equinox
|
| While we are at it, we could also do something more clever than
| months, weeks and the time system. 24/60/60 is a pain.
| BjoernKW wrote:
| Part marketing ploy, part genuine attempt to improve time
| systems, especially in a global context, Swatch actually once
| tried to do so:
| https://en.m.wikipedia.org/wiki/Swatch_Internet_Time
|
| Unfortunately, .beat time didn't catch on.
| iso1631 wrote:
| For most people, going to work on Monday and coming home on
| Tuesday isn't going to catch on (yes some of us work nights,
| it's rare)
| andruby wrote:
| I have often wondered why 10 days after the shortest day was
| chosen to start the year (Jan 1). Does anyone know why they
| chose that?
| yboris wrote:
| Obligatory post to _Computerphile_ episode about Timezones - a
| must watch for developers just starting out with Timezones
|
| https://www.youtube.com/watch?v=-5wpm-gesOY
| NovemberWhiskey wrote:
| I work with a proprietary programming language that internally
| models a _date_time_ as a UNIX epoch offset. The _to_string_
| method of a _date_time_ results in a nice human readable string
| in the local timezone, but crucially not including the TZ itself.
| There were also accessors for the HH:MM:SS parts of the
| _date_time_.
|
| At some point, the problem must've come up "if it's 5pm here in
| SFO, what time is it in MIA?", or some variation on that theme.
|
| Someone decided that the best way to answer this was to write a
| function that took a _date_time_ , then altered it to apply an
| offset between timezones. e.g. _time_local_to_tz_.
|
| So you can could take a _date_time_ in SFO, do _time_local_to_tz_
| (supplying Miami 's TZ) and get back a _date_time_ value that
| would _to_string_ in SFO to show "the time in MIA". These
| functions made their way into a standard library and then to a
| lot of code.
|
| The only problem is that the assumptions are literally all wrong.
| Adding the offset changes the actual point in time being
| addressed, which can change the timezone in effect in the current
| location, which results in the result skewing. This was
| compounded by some developers assuming that maybe they should
| convert their times to UTC before persisting them.
|
| Of course, the usage of these functions is now embedded in a
| bunch of code no-one dares to touch, because it is full of hacks
| to "make it work" and quite possibly there is other code
| somewhere else (separated by a network connection, or a file, or
| persistence into a database) that is predicated on undoing those
| same set of hacks.
| twic wrote:
| I wrote an app that does a different but perhaps even more
| appalling crime.
|
| The app was for displaying time-series data. The data displayed
| was only generated during business hours. We usually wanted to
| view a span of a couple of weeks. Displaying it naively, with
| real time along the x-axis would mean that three-quarters of
| the display was blank, with only 40 of a week's 168 hours in
| use.
|
| The obvious thing to do is to elide the blank bits, and just
| show the spans of time with data (with a little gap in
| between). But the charting library i was using didn't have the
| concept of a discontinuous or nonlinear x-axis.
|
| So i wrote a class called TimeCompressor that would collect a
| set of time-series data, indexed by epoch timestamp, and
| rewrite the timestamps so that empty spans of time would be
| compressed. The earliest timestamp in the dataset stays the
| same, but later ones may be slid earlier in time to compress
| empty spans. The resulting indices are numbers which _look
| mostly like_ epoch timestamps, and in some cases actually are
| epoch timestamps, but really aren 't epoch timestamps.
|
| This was all done in JavaScript, so there wasn't a convenient
| way to wrap the not-really-timestamp indices in a type to mark
| them as such. So, in this application, when there's a field
| called somethingTimestamp and it has a large integer that looks
| like a timestamp in it, sometimes it's a timestamp, and
| sometimes it isn't!
|
| I am hoping this application will be retired before i ever need
| to work on it again.
| larrik wrote:
| > Either use the tzdb name like America/New_York, or use an
| offset from UTC, depending on what you want.
|
| I bet storing an offset is far more pain, given that anyone in a
| DST area will have 2 offsets per year.
| shadowgovt wrote:
| Offsets can very easily be the wrong answer (though the author
| is quite correct that it depends on what you're trying to do).
| If your user intends to use one of the timezones that has a
| daylight savings calculation, the offset changes as the year
| goes on. Offsets can also change if the definition of the
| timezone itself changes (Russia ceased to use daylight savings
| in 2014).
|
| Offsets _can_ be useful if one is attempting to record a
| historical incident, where the timezone had a particular-
| defined offset at the point in time the incident occurred
| (though for my money, I 'd just convert that time to UTC on
| storage).
| shadowgovt wrote:
| Time calculation is deceptively hard.
|
| Here's a fun one: are timezones a mathematical construct or a
| physical construct? By which I mean: is the core of the problem
| to get the math right or to account for the geography of the
| planet?
|
| It's a trick question. Timezones are a political construct. If
| your software is using timezones, it needs to somehow(1) account
| for changes to law, internationally. Individual countries can
| choose, for example, to use or stop using daylight savings time.
| Some have even chosen to shift the longitudinal timezone they
| consider themselves to be in.
|
| (1) practically speaking, relying on tzdata
| (https://en.wikipedia.org/wiki/Tz_database) is a great solution
| to this problem for most use cases... But you need to keep your
| copy of it updated, because laws change.
| bob1029 wrote:
| The only situation where our datetime instances deal with
| timezones is on a one way trip to a user's display, document or
| email. If you are playing around with parsing timezone strings,
| you are probably making a huge mistake unless you are parsing
| someone else's trash data.
|
| I feel the standard interchange format for datetimes really
| should be 64 bit Unix timestamps. These are trivial to store in
| any database as a native type, can be compared using the fastest
| arithmetic instructions possible, and are a locale agnostic
| representation suitable for direct business logic comparisons.
|
| Trying to carry timezone information around is a mistake. This is
| state that should be terminated and normalized at both ends, not
| passed through the system.
|
| The only thing I would store pertaining to timezone is for user
| profile or server environment configuration. These would be
| settings in the application that are used to produce locale-
| specific UI and reports.
|
| There are probably some other use cases I am not thinking of, but
| that is the extent of how we do it and we have a really complex
| app that has to serve customers who operate in multiple timezones
| at once.
| netsharc wrote:
| Hmm, your applications don't have user input asking for a time?
| bob1029 wrote:
| We do have one case where we do have to capture the hour of
| day for an IT activity. In this situation, we present the UI
| in the timezone configured by the customer's server and
| additionally display this timezone information in the UI as
| reference/confirmation for the user. Once the user submits
| their input in terms of server-local time, we immediately
| convert it to UTC for storage in our system. Note that
| because we present the actual TZ info, this even supports
| servers that are already configured for UTC. We have no edge
| cases aside from ensuring our users pay attention to the TZ
| info.
|
| I still don't understand the arguments about a future date
| requiring a timezone. UTC can 100% accurately represent a
| future date or event without any ambiguity. If a user,
| meeting or other aggregate has a culture/timezone preference,
| this is a completely separate business fact from the time.
| shhsshs wrote:
| > I still don't understand the arguments about a future
| date requiring a timezone.
|
| It's not that a future date requires a time zone, you are
| right that can be 100% represented with a fixed timestamp.
| But there is the extreme case that time zone rules may
| change from the time you schedule the event to the time it
| happens, and in that case your event is now at the wrong
| time.
|
| Consider the case where you have a weekly meeting at 9:00
| AM on Tuesdays in an America/Chicago office. You could
| surely calculate the next N weeks of meetings and save them
| as UTC timestamps, taking into account that we shift into
| daylight savings time at some point, so you end up with a
| nice list of timestamps at 9:00 local time. But if the time
| zone rules change at any point (say, Chicago decides not to
| observe daylight savings time any more), now all of your
| meetings are an hour off.
|
| If you had saved the meetings in a more verbose but true-
| to-intent format that properly captures "Every Tuesday at
| 9:00 AM America/Chicago", then at the time those rules
| changed you would either automatically have updated meeting
| timestamps, or some consolidation process could go and
| update the meeting times.
|
| Even without sweeping changes like that, we still have
| unscheduled leap seconds, minutes, etc. every once in a
| while, which will also mess up your timestamps. I'm
| actually excited to see the day my calendar somehow ends up
| with a meeting at exactly 9:00:01.
| soco wrote:
| The GUI elements should have nothing to do with storing and
| interchanging timestamps. What you display can query the
| browser timezone to make it look nice, then send it down
| converted, over.
| stefan_ wrote:
| Ding ding ding, we got a winner. No, absolutely do not
| query the timezone once then "convert" (aka remove) the
| information. Timezones change _all the time_.
| soco wrote:
| There's a (fresh) extensive comment right above mine
| which explains the 4 different use cases for dates and
| the very minimal real need of TZ, let's all read it.
| Sorry I cannot comment otherwise your arguments because
| you didn't offer any.
| user-the-name wrote:
| And if the timezone changes, should the meeting you
| booked at 9 AM now happen at 8 AM?
| seszett wrote:
| You cannot convert a time string in the future to a
| timestamp. You must keep it as a string with timezone
| information until the time actually comes.
| netsharc wrote:
| IMO depending on the use case, just the TZ info won't
| save you. Say I arrange a meeting for 4pm local time
| (where summer daylight savings time will be active) for
| July 2022.. and then the city I want to meet in gets
| invaded by a foreign army and changes its timezone. And
| cancels summer time. What time is my meeting now?
|
| I guess it needs to be a 4-dimensional coordinate, where
| 1 axis can slide around...
| kstenerud wrote:
| It's not quite so cut-and-dry. UNIX timestamps unfortunately
| don't solve the problems of time because they don't contain
| enough information.
|
| Time is something that developers get wrong more often than any
| other type. Your time data requirements change as your use case
| for the time changes.
|
| From https://github.com/kstenerud/compact-
| time/blob/master/compac...
|
| Aside from issues of synchronization, leap seconds, data
| container limitations and such, it's important to choose the
| correct kind of time to store, and the right kind depends on
| what the purpose of recording the time is.
|
| There are three main kinds of time:
|
| *Absolute Time*
|
| Absolute time is a time that is fixed relative to UTC (or
| relative to an offset from UTC). It is not affected by daylight
| savings time, nor will it ever change if an area's time zone
| changes for political reasons. Absolute time is best recorded
| in the UTC time zone, and is mostly useful for events in the
| past (because the time zone is now fixed at the time of the
| event, so it probably no longer matters what specific time zone
| was in effect).
|
| *Fixed Time*
|
| Fixed time is a time that is fixed to a particular place, and
| that place has a time zone associated with it (but the time
| zone might change for political reasons in the future,for
| example with daylight savings). If the venue changes, only the
| time zone data needs to be updated. An example would be an
| appointment in London this coming October 12th at 10:30.
|
| *Floating Time*
|
| Floating (or local) time is always relative to the time zone of
| the observer. If you travel and change time zones, floating
| time changes zones with you. If you and another observer are in
| different time zones and observe the same floating time value,
| the absolute times you calculate will be different. An example
| would be your 8:00 morning workout.
|
| *When to Use Each Kind*
|
| Use whichever kind of time most succinctly and completely
| handles your time needs. Don't depend on time zone information
| as a proxy for a location; that's depending on a side effect,
| which is always brittle. Always store location information
| separately if it's important.
|
| Examples:
|
| Recording an event: Absolute
|
| Log entries: Absolute
|
| An appointment: Fixed
|
| Your daily schedule: Floating
|
| Deadlines: Usually fixed time, but possibly absolute time.
| lolc wrote:
| Interesting to see fixed and floating time differentiated. I
| didn't really have a name for that last concept.
|
| And fixed time I would call local time. Why call it fixed?
| Because it's tied to a location?
| detaro wrote:
| Human-decided events in the future are an obvious example. E.g.
| "every second Tuesday at 8:00" or "May 17, 2025, 8:00"
| shouldn't ever happen at 7 or 9, even if your software didn't
| have accurate DST information for that point available
| initially (which countries do change, sometimes with only a few
| weeks of warning!).
| tallanvor wrote:
| What if you're scheduling a meeting for multiple people, and
| normally you're in Seattle, but for some of these meetings
| you'll be in New York? You don't want the meeting to be at
| 8:00 your time because chances are the people in Seattle
| aren't going to join your call at 5:00 their time.
| detaro wrote:
| A meetings timezone can be independent of a users, yes.
| E.g. the meeting time should be specified as e.g. "8:00
| America/Los_Angeles" (or have a location-based lookup, but
| thats another level of indirection). That way it follows
| whatever DST rules there are, but your local phone time
| being in NY time only affects your display.
| ubermonkey wrote:
| As someone who routinely sets meetings for people in
| multiple timezones, let me say this isn't confusing.
|
| All the calendaring tools I use or am aware of, at this
| point, keep up with time zone correctly (or have so far). I
| set the meeting for, say, 10 CST, and it's clear to my
| colleagues in Seattle that it will be 8 for them, just as
| it's clear for my coworkers in DC that it'll be 11.
| kevincox wrote:
| There are still edge cases.
|
| What if you schedule a meeting in a year's time in a
| timezone that doesn't have Daylight Savings Time but that
| government decides to add it and now the meeting is at a
| time that doesn't exist?
|
| But your use case it also talking about when using a tool
| that is specifically designed to deal with this issue.
| What about when you are trying to find a good time (AFAIK
| most calendars don't have good tooling for
| collaboratively choosing a meeting time). If you do this
| in your favourite chat app then you probably have no
| timezone support. (This would be an awesome feature
| though)
| bslorence wrote:
| Twice a year we have to deal with calendar screw-ups
| because a third of our employees are in a locale that
| doesn't observe DST and the rest are in locales that do
| observe it. If an employee from that first group sets up
| a recurring meeting, the meeting time changes for
| everyone else in March and November.
| bloak wrote:
| > I feel the standard interchange format for datetimes really
| should be 64 bit Unix timestamps.
|
| Several people have already replied pointing out that for
| scheduling events in the future, particularly recurring events,
| it's practically necessary to refer to time zones.
|
| So I'll just mention the problem of leap seconds, which are
| announced six months in advance. If a one-second error could
| cause problems then probably you should use TAI rather than
| UTC. But you still need UTC for other purposes, so probably you
| need both and so you need to keep track of whether a particular
| timestamp is TAI or UTC.
| levosmetalo wrote:
| And then your application has to schedule a recurring weekly
| meeting happening at exactly 9:00 CST, and suddenly, you have
| to update your DB schema and all code instances everywhere to
| actually deal with the time zones. And then you realize you'd
| be better off if you were just using a sane time zone library
| from the start instead of pretending time zones don't exist.
| WatchDog wrote:
| They are different things.
|
| You store your datetimes/instants as UTC, you store your
| "every day at 9 CST" rule separate from that.
|
| Your rule table might have a column for a cron expression,
| and a column for the tz database name.
|
| Meanwhile, your table for the meeting records has the time
| represented as a UTC timestamp.
| phlo wrote:
| And to stay with the theme of the article: Chances are, the
| meeting actually _isn't_ intended to be scheduled for 9am
| CST, but rather 9am America/Chicago. The key difference
| being that Chicago only observes CST for half of the year,
| and most people would probably expect for their recurring
| meeting to happen at the same local time, regardless of the
| season.
|
| If the meeting is in _the other_ CST (the Taipei one),
| there's good news: Taipei doesn't do daylight savings. On
| the flip side, Chicago attendees might dial in fourteen
| hours early, so Asia/Taipei is a safer bet, too.
| pjungwir wrote:
| I agree with this, mostly.
|
| Besides the "meeting time" exception others have mentioned, you
| should be aware of timezones when grouping records into
| days/weeks/months/years/etc. The timezone affects where you
| "cut" the continuum into groups. Does Joe's sale count toward
| his January quota or February? This has all kinds of
| interesting questions: do you use the user's time zone? The
| local office timezone? The HQ timezone? UTC for everything?
| What if the user moves? Stack Overflow's "fanatic" badge just
| uses UTC: https://stackoverflow.com/help/badges/83/fanatic
| rbanffy wrote:
| > Trying to carry timezone information around is a mistake.
|
| No.
|
| If a human says a recurring meeting happens at 9 AM Pacific
| time and the following week they are in daylight saving time,
| it'll still happen at 9 AM local time. Preserving intent is
| crucial in this case.
| arkh wrote:
| Even better with "virtual meetings": 9AM in which user
| timezone? Sometime people move and they still expect the
| meeting to happen at 9am for them.
| ttymck wrote:
| isn't that a local time and not a timestamp/datetime?
| kelnos wrote:
| Sort of. If you expect to have to deal with people in other
| time zones, though, you still need to carry time zone
| information, so the person who lives in New York will
| correctly dial in to the meeting at their noon and not
| their 9am.
|
| (This also raises the point that you need to preserve
| _zone_ information, not just the UTC offset. Otherwise the
| meeting will move after a daylight saving time change,
| which is not usually what people want.)
| hyperpape wrote:
| Other commenters are right, one article that lays out the case
| that there are plenty of times what you say isn't right:
| https://zachholman.com/talk/utc-is-enough-for-everyone-right.
|
| Use UTC everywhere, then display in the user's timezone is a
| perfectly valid pattern...for specific use cases. Those use
| cases are very common, but many people over generalize, and
| assume that it can handle all cases.
| zokier wrote:
| > I feel the standard interchange format for datetimes really
| should be 64 bit Unix timestamps.
|
| UNIX timestamps are ambiguous.
|
| ISO 8601 is perfectly good interchange format.
| apaprocki wrote:
| Really disappointed that the author did not want to delve into TZ
| dark magic: $ date &&
| TZ=LOLS-3:03:03LOLD,J101,J202 date Wed Feb 10 17:44:44 EST
| 2021 Thu Feb 11 01:47:47 LOLS 2021
|
| (My timezone is LOL Standard Time (LOLS), UTC+03:03:03, with
| support for changing to LOL Daylight Time (LOLD) during daylight
| savings, entering LOLD on the 101st Julian day of the calendar,
| and leaving on the 202nd Julian day of the calendar, excluding
| February 29th even in leap years.)
___________________________________________________________________
(page generated 2021-02-10 23:01 UTC)