1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Daylight savings date identification over the net

Discussion in 'Embedded' started by Dimiter_Popoff, Mar 30, 2014.

  1. Indeed. BTDTGTTS.
    From being involved with telecom accounting we made a very good
    decision early on. EVERY log file has UTC times internally, and
    as they are forwarded from the various controllers to the
    accounting systems. The accounting system also works in UTC.

    The timezones may then be added ona per-user base just before
    the finished print. Or not. It is simple to make the accounting
    periods follow UTC in the contracts.

    -- mrr
    Morten Reistad, Mar 30, 2014
    1. Advertisements

  2. Why does everyone confuse the displayed time with the time stored in
    a file or database and assume they are the one and the same ?

    If possible, you should always store away timestamps in one permanent
    timezone, say GMT, and then use the timezone database to determine what
    the local time offset is from that stored time.

    That way, there are no jumps in the (say) on-disk recorded time regardless
    of any timezone changes. Linux does this (and I believe Unix in general
    does as well) and it works cleanly.

    BTW, I have a VMS background and I have seen first hand the mess that is
    timezone handling when you assume displayed time equals stored time. :)

    Simon Clubley, Mar 31, 2014
    1. Advertisements

  3. Except that in some domains all days are 24 hours long (or in one case
    all days are about 23 hours, 56 minutes, and 4 seconds long)
    Unless they are dealing in UT1, which does NOT have leap seconds.
    Yes, knowing that other answers (for other definitions) are possible is
    good, but for a very reasonable definition of month and year, 12 IS the

    Looking at other answers you have accepted, you are demonstrating
    another bias, for example one answer to the number of days in a year is 1/2.
    Richard Damon, Mar 31, 2014
  4. Dimiter_Popoff

    David Brown Guest

    I've been considering GMT, rather than local time. I guess I should
    have read the title of the thread!
    I didn't know you could get two leap seconds in one year. It is not
    uncommon to see time utilities, RTC's, etc., that support seconds counts
    in the range 0..60 so that they can handle a leap second - but not two
    leap seconds (see "man date" for example - and that's a *nix command,
    not a recommended google search....).

    I suppose it is also possible for a lost leap second to give 59 seconds
    in a minute on occasion.
    David Brown, Mar 31, 2014
  5. Dimiter_Popoff

    upsidedown Guest

    In 1972 one second was added after Jun 30 and an other second after
    Dec 31. Technically, one could add 12 leap seconds in one year, each
    after any month, but always only one second at a time.
    upsidedown, Mar 31, 2014
  6. I agree basically, the thing is that our spectrometers are completely
    self-sufficient, they do run an OS (DPS) with its filesystem,
    UI etc., one can access them from any platform which has a VNC
    viewer application (windows, linux, android have been used so far).

    Obviously time is stored as UTC - in directory entries, within spectra
    etc., however one has to deal also with the time for user
    interpretation. File dates are preferred in local time (usually I
    suppose, so far so good with that). On spectrum evaluation results
    the time is accompanied by the GMT offset so there is no ambiguity
    there either (pretty much like time was defined in rfc822 I think,
    except for leaving out the leading 0 of the hours - a mistake I
    have made many years ago which I have not had to fix yet and leave so
    in the hope the world will catch up with my better
    representation :D :D ).

    Dimiter_Popoff, Mar 31, 2014
  7. This is the only sane solution, this is how DPS (the OS under which
    our devices work) maintains time. In the newer (longnamed) directory
    entry type time is stored in uS since Jan 1 1970, 64 bits. Current
    devices do not support the entire precision but the format is there.
    Older (shortnamed) directories store seconds. Somewhere in the 90-s
    (the initial format of the shortnamed - 8.4 - directory entry was
    set in 1994 or 1995) I had to bite the bullet and change to
    seconds since 1.1.1970, had not thought enough of it when starting
    the entire endeavour. I think even now the old format can
    be recognized and read more or less correctly from old disks...
    Yes, once one has the correct unambiguous data representation
    is just a matter of choice.

    Dimiter_Popoff, Mar 31, 2014
  8. Dimiter_Popoff

    Tom Gardner Guest

    Sure, but that is not everyday (or perhaps every semiyear!)
    experience for the "man on the Clapham omnibus", whereas
    23/24/25 is (except '68-'70 in the UK!).

    If they can't get everyday experience right, there's no
    point in considering the "subtleties"!

    If they know the concept of UT1, they'll know the rest - or
    at least know they have to go and research the answer. That's
    fine by me.
    I'm not aware of anything other than 12 being used for
    civil purposes, but some calendars do contain 13 months.

    Unless you're thinking of non-terrestrial calendars,
    you'll have to explain that one!
    Tom Gardner, Mar 31, 2014
  9. Dimiter_Popoff

    David Brown Guest

    13 months makes sense for calendars based on lunar months, although of
    course there are not exactly 13 lunar months in a year.
    No need for an explanation, then :)

    (It's Mercury, to save you looking it up.)
    David Brown, Mar 31, 2014
  10. Dimiter_Popoff

    Tom Gardner Guest

    Yet another example of "10% more difficult than expected, recursively"!
    Suspected so, couldn't be bothered to google :)
    Tom Gardner, Mar 31, 2014
  11. Actually every day IS about 23 hours, 56 minutes and 4 seconds long, IF
    you are dealing with Sidereal days.

    If you are saying that Sidereal days aren't important because they
    aren't and "everyday experience", then neither are other than 12 months
    to a year.
    Yep, you were showing a Terran bias.
    Richard Damon, Mar 31, 2014
  12. Dimiter_Popoff

    Tom Gardner Guest

    The original question was about calendars, and I'm not
    aware of any calendars based on the sidereal day.

    But that could be another example of the "10% recursive"!
    I haven't said that, of course.
    Do you have any pointers to non-terran calendars?
    Tom Gardner, Mar 31, 2014
  13. Yes. There's the calender as used on Mars.

    Simon Clubley, Mar 31, 2014
  14. And before someone thinks I've lost the plot :), Google for

    NASA living on Mars time

    (and similar search strings)

    at which point you will find NASA employees have some direct experience
    of living by a Mars calender. :)

    Simon Clubley, Mar 31, 2014
  15. Dimiter_Popoff

    Tom Gardner Guest

    If it isn't in the tz database, it doesn't exist. Bah.

    Oh, if you insist :)
    Must try and get some astrologers to define what it means
    to have "Earth in the ascendent" and not "Mars in the
    ascendent" :) And it that's astrological gibberish, then...
    .... how can anybody tell?

    (No. I'm not going to google it. On principle.)
    Tom Gardner, Mar 31, 2014
  16. Dimiter_Popoff

    WangoTango Guest

    I'm sure they just keep the RTC running GMT or local standard time and
    just adjust for DLS by massaging that data and NOT messing with the RTC,
    but that may be too much for a small MCU to handle on the fly.
    I have done it the "bad" way, which can drift the clock a few seconds
    per year, on top of the clock's drift, depending on how fast you can
    pull it all off. I have a DLS flag held in the RTC's free battery
    backed RAM and I check the time and date against that flag and actually
    update the RTC accordingly. I wrote a set of routines to check if the
    date and time falls inside the DLS period and go from there. I saw one
    implementation that just hard coded the next 10 years of DLS dates and
    times in a lookup table and adjusted the RTC accordingly.

    I do have one product that I just don't do it, the owner just adjusts
    the time when they go to collect the cash in the unit. Which is usually
    WangoTango, Mar 31, 2014
  17. Then why were there questions about seconds in a minute or hours in a
    day, these are not calendar questions either.
    Here are some found with a bit of searching.



    (well, this MIGHT be considered terran)

    Of course, until we get to some other planet, or meet someone who has,
    these will be be a bit academic. The "Working on Mars Time", was
    interesting, while the period was short enough they really didn't get to
    calendars, they did get to clocks.

    Richard Damon, Apr 1, 2014
  18. Dimiter_Popoff

    Tom Gardner Guest

    The number of hours in a day depends on the day of the
    year - hence calendar information is inherently required
    That is reflected in the API of software libraries; many
    default to a particular locale but allow you to set the locale.

    Um, I was looking for something with at least a
    tiny basis in reality.

    I suspected as much.

    Anything less fictional? Astrological calendars don't count!
    Tom Gardner, Apr 1, 2014
  19. Actually, if you look up the definitions of hours, and day, you should
    find that for most reasonable definitions of "day", you will get that a
    day is 24 hours (for earth) for EVERY day. It is only for this strange
    beasty of a "calendar day", or something artificial like "wall clock
    time" that we get the exception, and this strangeness. You also need to
    add into the equation where you are talking about, as there are
    locations which never to this shifting, and others that do it at other
    times, so just having a calendar isn't good enough.

    So, you say that just because you haven't meet the people using the
    calendar it doesn't exist? At that point you need to accept that a
    person may consider that there are always 12 months in a year, and even
    that as far as they are concerned, always 24 hours in a day (they may be
    from a place without DST).
    Richard Damon, Apr 3, 2014
  20. Dimiter_Popoff

    upsidedown Guest

    While the _mean_ solar day is exactly 24 hours or 86400 seconds, the
    actual solar time as measured by a sun dial or more scientifically
    using a telescope to detect when the sun is in south (actually in the
    meridian, depending on hemisphere) is not constant, but can vary
    nearly a minute, causing +/-20 minute cumulative difference between
    actual solar time and mean solar time twice a year and slightly
    smaller peaks in between.

    Before railroads and telegraphs, each city used their own mean solar
    time. There was a small village outside London with a naval
    observation, which their own local _mean_ solar time, which later
    became GMT (after changing definition from noon-to-noon to
    midnight-to-midnight :).
    upsidedown, Apr 3, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.