Results 1 to 12 of 12

Thread: Firemonkey TDateEdit met bug in datum

  1. #1

    Firemonkey TDateEdit met bug in datum

    Hallo,

    Ik heb een heel vreemd gebeuren met een TDateEdit. Onder iOS en Android springt, als je een jaar hebt gekozen < 1964, het jaar steevast naar 100 jaar verder (dus bijv. 1961 wordt automatisch 2061). In eerste instantie viel dit niet op, omdat slechts de laatste 2 cijfers worden weergegeven worden, maar ik zag het toen ik er een leeftijd aan koppelde. Onder Windows geen probleem, probleem is alleen bij iOS en Android.
    Iemand hier ervaring mee/oplossingen?
    Add one binary to 1, and suddenly
    you end up with 10.

  2. #2
    mnemonics
    Guest
    Heeft dat niet gewoon met Unix/Linux te maken?
    "1 January 1970 00:00:00"
    Even zoeken op google genoeg over te vinden

    Hier staat een voorbeeld:
    http://stackoverflow.com/questions/9...atetime-in-del

  3. #3
    Lijkt me sterk. Opvragen van een oude datum uit een database, encodedate, datetostr, die werken allemaal zoals verwacht. Probleem is ook niet 1970, maar specifiek datums vóór 01.01.1964

  4. #4
    Senior Member
    Join Date
    Sep 2003
    Location
    Merendree, België
    Posts
    224
    Het heeft er mee te maken dat men schakelt op 50 jaar vroeger en 50 jaar later...
    Laat 1964 nu net 50 jaar geleden zijn. Aangezien je maar 2 cijfers van het jaartal toont, en je dan bv. het jaar '63' selecteert, dan zegt de component: hmm, 63 dat is al zo lang geleden, vermoedelijk bedoelt de gebruiker '2063'... met het gekende gevolg.
    Als je dezelfde toepassing dan bv. volgend jaar in 2015 gaat draaien, dan duikt het probleem op met datums voor 1965 i.p.v. 1964. En zo schuift dat dus ieder jaar op...
    Life is too short, don't stress every day

  5. #5
    Ok, kan ik me iets hij voorstellen, klinkt logisch (hoewel de control op zowel iOS als Android toch wel de eeuw laat zien tijdens selecteren van een datum, en dit verschijnsel onder Windows niet optreedt). Maar hoe los ik dit nu op?

  6. #6
    Senior member mzwollo's Avatar
    Join Date
    Oct 2004
    Location
    Larserbos
    Posts
    155
    Hier staat de kern van het probleem en de oplossing:

    http://codeverge.com/embarcadero.del...monkey/1060506

  7. #7
    Is geen oplossing van het probleem.
    2 problemen:
    1: Als ik in de onchange van de control een showmessage (formatdatetime (datum vd control )) aanroep krijg ik ook het verkeerde jaartal te zien (geldt ook voor een onexit etc).

    2:Tijdens het kiezen van de datum ziet de gebruiker het volledige jaartal, inclusief eeuw, zowel op android als ios. Stel hij kiest een datum/jaar (1960) in de control, komt terug in het scherm, bedenkt dan dat het niet 1960 maar 1961 moest zijn. Klikt weer op de control in de veronderstelling dat hij uitkomt bij 1960, maar zal dan tot zijn grote verbazing zien dat de control op 2060 staat ipv 1960. Is niet prettig als er verschillende van zulke controls in je scherm staan (geboortedatums, schooldatums, werkdatums, pensioendatums etc.), je kunt ze dan niet meer vertrouwen.

  8. #8
    Helpt het niet om die TwoDigitYearCenturyWindow op 0 te zetten?
    (zoals de link van mzwollo al aan geeft)

    Code:
    TwoDigitYearCenturyWindow := 0;
    Standaard staat die TwoDigitYearCenturyWindow op 50 maar als je dus niet wilt werken met die 50 jaar rolling window zou je hem toch gewoon op 0 moeten kunnen zetten.

    Zie http://docwiki.embarcadero.com/Libra...rCenturyWindow

  9. #9
    mnemonics
    Guest
    Bij 2 cijferige gaat het inderdaad mis (getest met XE7) ook met windows.
    Maar vraag me af of het een bug is of dat het op een andere manier moet.
    In de help file staat nog wel het een en ander vermeld, daar zou ik eerst eens goed naar kijken.

    Hier gaat het namelijk wel weer goed vanaf 1999 , "TDate represents the number of days that have elapsed since 12/30/1899"
    Last edited by mnemonics; 19-Sep-14 at 23:35.

  10. #10
    TwoDigitYearCenturyWindow op 0 zetten werkt helemaal averechts, dan neemt 'ie standaard de eeuw van het jaar waarin we zitten (dus in dit geval altijd 2000). Maar heb het nu anders opgelost, in de OnEnter van de Control save ik de huidige FormatSettings.ShortDateFormat naar een global var, vul via een loopje de jaar-notitie aan tot 4 chars (waardoor de eeuw altijd wordt meegenomen in de Control), en in de OnExit van de Control zet ik de originele settings weer terug. Op deze manier kan ik altijd per Control bepalen of ik wel/niet van de 2-cijfer notatie gebruik wil maken.

    Op dezelfde manier zou ik natuurlijk ook de TwoDigitYearCenturyWindow kunnen aanpassen in de OnEnter (bijv. op 100 zetten, waardoor het "testpunt" op 1914 komt te liggen (voor dit jaar), heb nog niet getest met grotere waardes, bijv. 1000), maar denk dat ik voor de zekerheid toch bij de eerste oplossing blijf, jaar in ShortDateFormat aanvullen tot 4 chars (misschien opnemen in de OnCreate van de Form), dan heb ik ook niets met maken met de Delphi-Epoch (30-12-1899).
    Add one binary to 1, and suddenly
    you end up with 10.

  11. #11
    mnemonics
    Guest
    Dat lijkt me wel de beste oplossing, eerlijk gezegd vind ik het component ook niet netjes uitzien (bijvoorbeeld klopt de selectie al niet wanneer je de jaartal selecteert, 1 karakter te ver naar links).
    Misschien geen slecht idee om eens bij TMSSoftware te kijken die hebben wel een aardig setje voor firemonkey (ook native voor iOS, komt ook een stuk mooier over).

  12. #12
    Quote Originally Posted by TheMadMan View Post
    TwoDigitYearCenturyWindow op 0 zetten werkt helemaal averechts, dan neemt 'ie standaard de eeuw van het jaar waarin we zitten (dus in dit geval altijd 2000).
    Dan wordt er dus intern toch ergens gewerkt met YY als jaar (en niet YYYY zoals je kiest in je control).

    Quote Originally Posted by TheMadMan View Post
    ... in de OnEnter van de Control save ik de huidige FormatSettings.ShortDateFormat naar een global var, vul via een loopje de jaar-notitie aan tot 4 chars (waardoor de eeuw altijd wordt meegenomen in de Control)
    Wacht... Wil je zeggen dat het jaar in je FormatSettings.ShortDateFormat op YY staat (i.p.v. YYYY) ???
    Dat is natuurlijk vragen om moeilijkheden.
    Ik weet niet of dat iets is van Android (of Filemonkey onder Android?) maar ik zou de ShortDateFormat altijd op YYYY zetten.
    (Staat ie bij mij onder Windows in ieder geval altijd)

    Quote Originally Posted by TheMadMan View Post
    ... heb nog niet getest met grotere waardes, bijv. 1000)
    Groter dan 100 heeft geen zin want wat zou je dan met 05 doen? 1905? 1805? 1705? Als je dus altijd werkt met jaren in het verleden dan is 100 inderdaad de beste keuze. Maar dan moet je ook zeker weten dat je ook echt altijd met jaren uit het verleden te doen hebt.

    Quote Originally Posted by TheMadMan View Post
    ... maar denk dat ik voor de zekerheid toch bij de eerste oplossing blijf, jaar in ShortDateFormat aanvullen tot 4 chars (misschien opnemen in de OnCreate van de Form), dan heb ik ook niets met maken met de Delphi-Epoch (30-12-1899).
    Ja... ik denk dat de ShortDateFormat met YYYY vullen toch het beste is. Wat is het nadeel overigens om het gewoon op DD-MM-YYYY te laten staan? Waarom zou je hem terugzetten op DD-MM-YY ??? Ik denk n.l. dat dit niets aanpast in Android zelf (zoals in Windows) en dat die ShortDateFormat alleen binnen Delphi gebruikt wordt.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •